May 23, 2001
Attendees

* Jim Jokl (chair) - Virginia
* Judith Boettcher - CREN
* Michelle Gildea - CREN
* Ed Feustel - Dartmouth
* Bob Brentrup - Dartmouth
* Bob Morgan - Washington
* Eric Norman - Wisconsin
* Deb Crocker - Alabama
* Renee Frost - Michigan/Internet2
* Ellen Vaughan - Internet2
* Chris Misra - Massachusetts
* Michael Gettes - Georgetown
* Bill Doster - Michigan
* Jeff Schiller - MIT/CREN
* Ben Chinowsky (scribe) - Internet2

Discussion

The minutes of the previous meeting (April 25; there was no meeting on May 9) were approved, with a clarification of Eric's suggested alternative to key escrow. The group reviewed the action items from the April 25 call:

[Judith will ensure that CREN's profile is reviewed by HEPKI-TAG to ensure it is consistent with accepted practices.] Judith noted that while there is no CRL pointer in the CREN root cert, the institutional certs will have a pointer to a CRL in the CREN repository.

[Whether this extension could be added without the private key of the requesting certificate was to be posed to Jeff.] Anyone requesting an institutional cert can get the CRL pointer extension, starting now; there is no need to reissue the root, so the private key is not required.

[Judith will look at the exact wording of the draft policy to identify the ripple effect of revocation.] Not done yet. [AI] On the next call, TAG will look at the question of whether institutions should be required, or only encouraged, to maintain their own CRLs.

[An old spreadsheet housed on CREN has been sent to the list multiple times in the past, and Jim will update this with the new data and send it out again. [sub-AI] Judith will link to it from the CREN site.] Jim has sent the updated PKI apps spreadsheet to the list.

[The usability study's results will be forwarded to the list.] Still to do.

[In response to this, Judith will work to help update these PKI pages with additional information, especially from a survey of the institutions participating in the January seminar.] Done; see www.cren.net/ca/SurvSynop.html and www.cren.net/ca/crencert.html.

[The draft document already created for the J-STOR pilot will be mailed to the list by Judith.] Done.

There was a short report on the progress of the ID cert profile work; this group is focusing on making the cert as simple as possible, with a narrowly-defined purpose, and therefore few fields. Ed noted that the number of fields will expand as we go along; we can issue short term certs first, and reissue as the profile expands.

Most of the call was taken up by a discussion of the pros and cons of doing a PKI Lite project. The central question is: Once a PKI has shed technologies, procedures and (above all) policies to the extent necessary to make it significantly easier to implement, what would it still be good for, and could it serve as a bridge to a full PKI? There was general agreement that a lightweight PKI would have to stick to the Rudimentary and (at best) Basic assurance levels; given this constraint, several possible applications were discussed:

- Bob Morgan noted that "for better or worse" the University of Washington hospital is going to roll out SecurID, and expressed his conviction that, at UW and at other medical centers, a full PKI would be a much better solution than either SecurID or the username/password authentication that it replaces. In Bob's opinion, gaining experience with a PKI Lite would be a significant step toward a full PKI. - Ed noted that Dartmouth maintains a medical almanac and needs to "keep Congress happy with the way we keep that data". This application would likely require more than PKI Lite, but less than a full PKI. - Judith suggested that PKI Lite be used for secure email, e.g., for sending grades and health records. - The group noted that the US Postal Service is getting ready to implement secure email, via a huge contract with Microsoft. Ed suggested that HEPKI might be able to piggyback on this decidedly non-Lite effort in some way, thus lightening its own load; this suggestion was met with general skepticism. - Ken suggested that PKI Lite be used for signed-but-not-encrypted email. There was general agreement that, while this would not be useful for grades or health records, universities would find it useful in many other areas; for example, announcements from university officials or requests to university maintenance services could be shown to really be coming from their purported senders. Without encryption, key escrow would not be required; this would be a big plus. The group explored the possibility of non-cert approaches in this area: the Postal Service is setting up a timestamp authority (the standards defining it are currently waiting for IESG review); Surety, a PGP timestamp service, is already operating, but this is a patented approach; Adobe iForms could also be used. None of these approaches seem obviously better than PKI Lite. Ken asked if anyone knew of any client-cert S/MIME work already underway on campus; the only example anyone came up with was at Wisconsin, where privacy of medical information, therefore encryption, is the main concern. - Ken and Bob Morgan suggested that the Shibboleth project could use PKI Lite to accommodate user-signed certs; Club Shibboleth policies could become cert policies. - Jeff noted that MIT has been very successful in using its PKI to replace username/password web authentication, successfully addressing the proliferating-passwords problem; Eric underscored the non-triviality of this achievement, noting that users are "clamoring for SSO".

No agreement was reached on applications around which to plan PKI Lite, or on whether to do PKI Lite at all. TAG will continue its discussion of this topic. Ken stressed the importance of evaluating what could be learned from different possible implementations of PKI Lite, especially in the areas of mobility, cert issuance, finding certs, and usability; he suggested that TAG make a list of the skill sets that PKI Lite would develop. [AI] Jim will write up the issues around PKI Lite for discussion on the TAG list.

Ed asked the group which campuses are already using directories for public keys; Princeton is doing so, and Virginia is setting up the infrastructure to do so. [AI] Ed will the send the list a request for information on current and planned deployments of directories for public key storage.

Finally, there was a short discussion of CA private key protection. Jeff is concerned that many institutions will just install OpenSSL and not appreciate the value of the information store they're creating, leaving it vulnerable to attackers. On the other hand, hardware solutions -- as at MIT, which is using SafeKeyper -- mean that the vendor, not the institution, is controlling access to the private key. SafeKeyper has been bought by Baltimore, which wants to migrate everyone to its products -- what if Jeff wants to use a competing product, rather than what Baltimore wants him to use? Jeff is documenting these dilemmas; [AI] All will review Jeff's private-key-protection document and send comments to Jeff.
Action Items

* [AI] On the next call, TAG will look at the question of whether institutions should be required, or only encouraged, to maintain their own CRLs.
* [AI] Jim will write up the issues around PKI Lite for discussion on the TAG list.
* [AI] Ed will send the list a request for information on current and planned deployments of directories for public key storage.
* [AI] All will review Jeff's private-key-protection document and send comments to Jeff.