*Internet2 PKI Labs Conference Call*
March 5, 2001

*Attendees*

Neal McBurnett (convener) - Avaya

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

Keith Hazelton - Wisconsin
Eric Norman - Wisconsin
Juanita Hung - Wisconsin

Bob Morgan - Washington
Jeff Schiller - MIT
Steve Bellovin - AT&T
Michael Gettes - Georgetown
Vishwa Prasad - AT&T
Cliff Neuman - ISI
Carl Ellison - Intel
Bob Moskowitz - ICSA Labs/TruSecure
Ken Klingenstein - Colorado/Internet2

Ben Chinowsky (scribe) - Internet2

*Discussion*

The minutes of the last meeting were approved without changes. Neal noted that Ben has started including URLs and other information sent to the list as part of the follow-up to each call, and asked the group's opinion of this procedure. There were no objections, but strong interest was expressed in also making the links available on the PKI Labs site, organized by subject. Bob Morgan noted that he's been "threatening for years" to put together a page of links on authorization, and that the PKI Labs would be a good context in which to do this. [AI] Bob Morgan will work with Ben and Neal to put together a list of authorization-related links for the PKI Labs site. Bob also asked the group to keep an eye out for other authorization pages.

The group then moved on to a discussion of work being done by IETF-AAA (see http://www.ietf.org/html.charters/aaa-charter.html), and its possible relevance to the PKI Labs. Steve noted that AAA has lately begun to work on "clean solutions", as vs. its previous focus on "RADIUS plus kludges". There was general agreement that AAA's work is worth tracking, though its focus on solving the current business problems of ISPs -- using PKI more for service-to-service than for user-to-user -- may limit its relevance to the concerns of the PKI Labs. Bob Morgan observed that the scope of OASIS's work is similar in this respect. Cliff reported that AAA has expressed some interest in picking up the GAA-API. It was noted that there is some similarity between AAA's approach and web-of-trust approaches (or more precisely, peer-to-peer approaches -- see http://world.std.com/~cme/html/web.html). Whenever an application needs a service, it contacts a server, which may contact another server, and so on -- if you regard the service as communication, you can see the these stacked ISPs as a distributed application. How much each has to know depends on what your security policy is -- for example, they may just trust each other, or the end service may need to know something about each server in the chain. There was general agreement that it would be useful to have someone more familiar with AAA (Bob Blakley and Bernard Aboba were mentioned) point the PKI Labs to some diagrams and lead a discussion.

Next was a discussion of the proposed PKI Labs workshop. Ken is concerned with how best to square this with the NSF middleware solicitation. There was general agreement that, while it would be best if NSF could sponsor this event, other options (Mellon and NIST were suggested) should also be investigated. [AI] Ken will continue to look for a sponsor for the PKI Labs workshop. It was noted that the tight timeline for the workshop will make it difficult for participants to prepare full papers; Ken suggested that two workshops be held, with the first targeted to get things moving and prepare the ground for the second and perhaps subsequent conferences. Cliff suggested that the Labs pursue publication of workshop papers in "ACM Transactions on Systems & Security", perhaps as a special issue. Ken suggested that the scope of the workshop -- should it be concerned only with large public-sector PKIs, or with PKI more generally? -- be considered in the light of the recent GAO report on the FPKI; he suspects that there will now be "a lot more paralysis" among the Feds. He summarized the report as saying "avoid bridges; can't your agencies have a single policy?" [AI] Ken will ask Peter Alterman and Tim Polk what to expect in FPKI over the next few months. There was a short digression on the subject of bridges, with Carl describing the FBCA as "the kiss of death" because it's tried to implement a traditional single-namespace-dependent PKI without eliminating the naming autonomy of each agency below it, and Michael, Bob Morgan, and Keith arguing that the FBCA's policies and name constraints are sufficient to ensure name uniqueness. Bob Morgan noted that while it is true that the FBCA approach will require that there be multiple certs per subscriber, having only one cert per subscriber was not a design goal for them anyway.

Next were updates from each of the Labs. Dartmouth is exploring PKI to support academic apps; the campus is "going mobile", which is likely to have implications for the PKI infrastructure. They're also looking for a way to tie their Kerberos infrastructure into their registration process. A student has been set to work comparing attribute-certs-issuing software tools, including Jonah and Peter Gutmann's Triplet, and the Lab's first PhD student is starting soon. The physical space for the Lab has been set up and the computers are on order. Bob Brentrup has put a lot of time into getting videoconferencing up and running; he expects most capabilities to be available by April or May, though little in the way of security will be available at first. Dartmouth and Wisconsin are preparing a joint proposal on high-performance data transfer.

Keith is pleased by the Labs' emphasis on shared work; Wisconsin and Dartmouth have been holding regular audioconferences, and have also done a trial videoconference, which went well -- "we'll be able to zoom in on whiteboards at least". Both Labs expect to be able to start issuing certs later this spring. Wisconsin has been working with Miron to get secure coprocessor software. Keith described Somesh Jha as "the closest thing we have to Sean Smith"; Somesh will be working with Eric Norman and Keith on authorization languages. Eric has been working on using Prolog to do X.509 chain processing; name constraints make this complex. [AI] Eric will put a sample of his Prolog X.509 chain processing work on the Wisconsin PKI Labs site, and notify the list. Eric noted that Somesh wants to layer a policy editor on top of the authorization language to get something a little more like natural language. Carl asked for a definition of "policy" in this context; Keith replied that their conception is broader than just controlling how certs are issued, encompassing all "assertions that weigh somewhere on allow/deny decisions."

Eric Norman expressed interest in the approach of implementing two completely independent policies, one for permissions and one for prohibitions. Carl objected to the non-monotonicity (for a explanation of this artificial-intelligence concept, see http://www.cs.bris.ac.uk/~flach/Conjectures/introduction.html#Preliminaries) that this introduces into a policy language; he remarked that the SPKI team had looked at the prohibitions approach and decided to "prohibit it from SPKI", thus keeping SPKI just as monotonic as conventional PKI. The SPKI team gave up on prohibitions because they assumed that certs would be delivered via a non-reliable path -- they didn't want the system to be open to attack via non-delivery of the cert. Eric acknowledged that making use of prohibitions would probably require a way to tie the negative information to the positive, requiring that both be delivered simultaneously.

The next call will take place on Monday, April 2, from 2:00pm to 3:30pm EDT.

*Action Items*

[AI] Bob Morgan will work with Ben and Neal to put together a list of authorization-related links for the PKI Labs site.
[AI] Ken will continue to look for a sponsor for the PKI Labs workshop.
[AI] Ken will ask Peter Alterman and Tim Polk what to expect in FPKI over the next few months.
[AI] Eric will put a sample of his Prolog X.509 chain processing work on the Wisconsin PKI Labs site, and notify the list.