*Internet2 PKI Labs Conference Call*
May 7, 2001

*Attendees*

Neal McBurnett (convener) - Avaya

Ed Feustel - Dartmouth
Sean Smith - Dartmouth
Bob Brentrup - Dartmouth

Keith Hazelton - Wisconsin
Eric Norman - Wisconsin

Carl Ellison - Intel
Cliff Neuman - ISI
Steve Bellovin - AT&T
Peter Honeyman - Michigan
Olga Kornievskaia - Michigan
Bob Morgan - Washington

Ben Chinowsky (scribe) - Internet2

*Discussion*

The call opened with informational items.
- Steve called the group's attention to NRC authentication and privacy work he is involved in; see http://www4.nationalacademies.org/cpsma/cstb.nsf/web/project_authentication/.
- Peter, Olga, and others at Michigan CITI have had a paper on their PKI accepted for publication.
- Ed noted that Dartmouth has been looking around to try to find out what other universities, in particular those who've gotten CREN certs, are doing with PKI, and the answer appears to be "not much". Dartmouth wants to find out if anyone has successfully gotten over the barriers to getting stuff going. Ben noted that the new emphasis in HEPKI is on creating a PKI Lite, modeled on MIT's approach; Keith remarked "I sense smiles all round", and there was no dissent. Ed said that PKI needs "an existence proof"; he mentioned several promising developments in the area of lightweight PKI, including an Indiana cert-issuing site, the Justice Department's effort with the State of Florida (which uses a form of authorization cert and a "very strong procedural basis for collecting info at the RA"), and security work done by the UK Advanced Network Systems Architecture (ANSA) consortium (see the official record of this project at http://www.ansa.co.uk). ANSA envisions a security architecture in which "things are relatively circular", with certificates that function like letters of credit. [AI] Ed will send the list citations for documents of relevance to a lightweight PKI. Eric noted Dean Purvey's approach of letting people do what they want, but prosecuting them if they are unable to explain their actions; Ed cited Virgil Gligor's identification of enforceable liability as the foundation of any workable security architecture.

There was a discussion of relationships among attributes, names and public keys in certs. Carl asserted that what you need to do is bind an attribute to a key; if you go indirectly, through a name, you've unnecessarily introduced a weakness. Raising the recent news of VeriSign having been tricked into issuing bogus Microsoft certs, Steve posed the question, given that lots of machines want to trust Micrsoft certs, how do you extend trust without the Microsoft name in the cert, and have it scale? It was agreed that the failure of large CAs like VeriSign to always be careful is a separate issue from the name being in the cert; the name is a reference for the user. Ed pointed out another problem revealed by the Microsoft/VeriSign episode: there was no CRL, so even if you wanted to check cert validity, you couldn't. There was no agreement as to whether "trusting the brand name Microsoft" or RA malfeasance was the more fundamental problem. Carl asserted that Microsoft should issue its own certs, and as a good example cited Neal's account of how Red Hat issues certs; "if you do the VeriSign approach right and do it only for certs with names in everyone's local dictionary, it works fine. It's when they start issuing certs for everybody else that there's a problem." Ed observed that the thing people tend to ignore is that while it's true that you shouldn't trust just a name, we don't have a mechanism that lets people trust more than that. Ed also remarked that the more dangerous thing today is not the certs that come with the browsers, but additional root keys accepted into the system with insufficient understanding on the part of the user. There was a short discussion of the idea of an Underwriters Labs for software security, which was discussed on Counterpane recently; a major issue here would be identifying an organization that could perform such a function.

There was further discussion of the idea of a PKI Lite. Ed noted that Jeff's basic approach seems to be "we don't really understand what we have to do to do a good job", so we should design to let us change things as we go; Ed suggested that "PKI Evolutionary" would be a better label than "PKI Lite". Bob Morgan noted that one thing that allowed MIT to proceed was that it avoided the signature issue; MIT doesn't support signed anything, and certs are used purely for authentication purposes. While HEPKI has done lots of work on a model CP/CPS, MIT doesn't have a written CP or CPS: "In reality the CPS for MIT is 'Talk to Jeff', which is the right answer in many cases". Bob also posed the question, "Does it have to be any more legally solid than the system you currently use?" Ed pointed out that by issuing relatively short-term certs, MIT allows for change of format and policies; Bob noted that certs are made easy enough to get that if a cert doesn't meet your needs, you can just get another one. A big issue is whether or not people would find PKI Lite compelling for deployment -- what applications would it make possible? Bob characterized the application at MIT as "authentication to web-based applications"; Ed estimated that this may cover 80% of what a campus wants to do.

There were short updates from Dartmouth and Wisconsin. At Dartmouth, Ed has gotten CDSA installed but has encountered problems, which time did not allow him to detail. Sean noted that Dartmouth has parceled out the PKI trust issues to various students, who are now making progress at various rates. [AI] For future calls, Neal will ask the Labs to send out summaries of ongoing work a week or so ahead of time. Keith noted that Wisconsin and Dartmouth have been working together on the NSF middleware proposal.

Also at Wisconsin, a recent RBAC conference provided Eric with an occasion to write some Prolog code to illustrate his thinking on authorization languages. Eric reported that he is almost at the point of being able to do SPKI; [AI] Carl will send Eric SPKI examples to use in his work on authorization languages. Keith observed that while Somesh Jha keeps saying that formalism, not language, is most important, Eric's approach is to try to do practical stuff with a language first, then work on the formalism later; Eric is trying to show that you can do "amazing things" with little code. Eric noted that using a role-based language, "you can just look in there and see where the attributes come out of"; there was general enthusiasm for this prospect. There was general support for Keith and Eric's approach of "not trying to write the whole dictionary, [but] trying to get the grammar" and concentrating on having a language sufficiently expressive to define new nouns and verbs in terms of old ones, as well as for the choice of Prolog as a vehicle for experimentation. Bob Morgan noted an intriguing idea discussed at the RBAC conference: people don't know what their roles are, so see if you could take an organization's HR info and permissions, apply artificial intelligence, and extract roles from that. Ed characterized this as "roles by example" and noted that DoD is considering a similar approach for security for joint task forces: have a set of rules about the duties of the task forces, outline what data sets are required to perform the tasks, try to describe the sensitivity of the data being exchanged, come up with roles. A problem is that the detail required is "horrendous". [AI] Ed will find out if the DoD's RBAC work is available to the public. Cliff noted that this work is related to the DARPA "dynamic coalitions" program (http://www.darpa.mil/ito/research/dc/), which is mostly open.

Keith noted that OASIS has started work on two security-related XML schemas, SAML and XACML, which he characterized as a "more fixed and stereotyped aspect of the language stuff". Eric observed that different interested parties are coming up with rules -- how to name things to avoid conflicts? How big does the dictionary have to be? Carl described this as a nice wide-open research topic: How do people find out, when they use the same words, that they don't mean the same thing? Eric suggested using a "sensive" approach -- use local vocabularies, but qualify them with a key before sending out. Keith observed that this is a sociological question; vocabularies will be smaller depending on the scale of the community, and as "it's hard work agreeing on anything", there can't be a global dictionary.

The next PKI Labs conference call will be Monday, June 4, at 2-3:30pm EDT.

*Action Items*

[AI] Ed will send the list citations for documents of relevance to a lightweight PKI.
[AI] For future calls, Neal will ask the Labs to send out summaries of ongoing work a week or so ahead of time.
[AI] Carl will send Eric SPKI examples to use in his work on authorization languages.
[AI] Ed will find out if the DoD's RBAC work is available to the public.