April 25, 2001
Attendees

* Jim Jokl (chair) - Virginia
* Judith Boettcher - CREN
* Bob Brentrup - Dartmouth
* Bill Doster - Michigan
* Ed Feustel - Dartmouth
* Renee Frost - Michigan/Internet2
* Michael Gettes - Georgetown
* Keith Hazelton - Wisconsin
* Ken Klingenstein - Colorado/Internet2
* Eric Norman - Wisconsin
* Neal McBurnett - Avaya
* Bob Morgan - Washington
* Jeff Schiller - MIT/CREN
* David Wasley - UCOP
* Deb Crocker - Alabama
* Nate Klingenstein (scribe) - Internet2

Discussion

The call opened with a short discussion of the April 11 minutes, which were approved with a minor edit on information about Sun boxes. The subsequent review of the action items inadvertently sparked several major, lengthy and productive discussions which eventually consumed most of the call.

The first action item from the April 11 draft minutes (Judith and Jeff will see that an extension for a pointer to a CRL is added to the CREN cert profile) launched a broad debate. The issue was whether CREN would maintain the CRL or OCSP service, or whether CREN would require a campus to publish a routine CRL before the institutional cert would be granted. Much of the confusion was attributed to misunderstandings about whether the cRLDistributionPoints (RFC 2459) field referred to the location to look for revocation of the certificate itself or of certificates created by the associated CA. The former is correct, which means that no modification to the CREN root certificate will be necessary. The cRLDistributionPoints will instead be signed into institutional certs and refer to a location at CREN storing revoked institutional certs issued by CREN.

Nevertheless, this initiated thought about whether a school should be required to maintain a CRL in order to be issued a CREN certificate. The observation was that the maintenance of the integrity of the certificates issued by an institution affects far more than a jeopardized certificate or its associated university; it affects the entire hierarchy to which the violated certificate belongs. To David's thinking, it's "very hard to imagine how it could be otherwise." Institutions may feel differently about whether or not CRLs are important to verify. For the sake of the applications and campuses that do desire to check revocation, every school must issue a CRL for there to be any model of trust for the system.

The concern was that this requirement would make compliance with CREN's policies too difficult, and institutions would seek certificates from another root-level signer such as VeriSign. Small institutions, or ones just starting out with PKI, would be daunted and hard-pressed to establish a functional CRL in order to be issued their signing key. Judith does want to ensure that CREN's profile is reviewed by HEPKI-TAG to ensure it is consistent with accepted practices, but did not commit to a timeline in Jeff's absence.

This requirement for revocation is in CREN's current draft certificate policy under section 4.1.1. Later in the call, Jeff made the recommendation that "imposing new and complicated rules is not the way to move forward in this business." Under the experience that a CRL is not essential from the first day, he recommended that institutions that were clearly not prepared to issue a CRL be issued signing keys which expire after six months or a year. During this time, the institution would be able to gain experience and skills working with PKI, and would be better equipped to comply with CRLs and other wise practices. Further, the shorter institutional certificate validity period would lessen possible exposure. Concerns were voiced that this time period would hardly be enough to prepare for issuing a whole fresh fleet of certificates at the expiration of the first signing certificate. Jeff responded that if everything is done correctly, the only certificate that needs to be embedded in servers is the CREN root certificate (which expires on Nov. 19, 2007). Jeff's other advice was to keep most information about a principal in a directory and concern end-user certs primarily with authentication. Campuses that were already clearly able to handle a signing key and CRL appropriately would be issued a certificate with a longer lifetime. This suggestion was generally agreed to, though several people recommended that a decision not be made until the applications survey has been completed, as the survey is expected to shed light on how important CRLs may, in some implementations, become.

The action item about displaying fingerprints on web sites developed into another discussion about what to do with the updating of many web pages in CREN's repository. CREN is close to deciding what to do about a page to identify the confusion about the certificate fingerprint discrepancies. Jeff said that "we look at this as people involved in PKI...and we're convinced there needs to be one answer and we worry we'll confuse the user if there's more than one. People are used to seeing things with multiple recalls. If you get one of these values, then you're OK." This was deemed possible and functional as long as there were not too many values, and other quirks such as IE's buffer overload and "font funnies" were explained. It was also suggested that CREN provide more information about why things are the way they are. Was HEPKI-TAG the first group to notice the discrepancy? "One of those chilling thoughts that occur on these calls all the time," said Bob Morgan.

The Dartmouth contingent had found interesting material on some other CREN pages that had not been updated since May of 2000. 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. An old spreadsheet housed there 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. Judith will link to it from the CREN site.

The discussion then turned to the question of bridges and PKI Lite, but instead developed into a discussion of the necessity of a CP/CPS in PKI Lite. The initial analogy offered by Jeff was the current protection of access by IP address. Contrary to intuition, being within the 18.* class A address does not require presence on campus, given technology such as IP tunneling and proxy servers. When some vendors asked for a guarantee that their IP-based restrictions would limit access to people affiliated with MIT, the campus could not ensure this. The same guarantee would be difficult to offer for a campus's certificates on a broad scale, as they may be issued to staff, students, alumni, or arbitrary other people at any given time. Additionally, because of the legal climate, MIT has so far been reluctant to issue a CP/CPS which would limit the ability of MIT to adapt and refine the content and usage of certificates. In Jeff's thinking, if people would respect clever wording to allow instant unilateral revision of the CPS, thus avoiding this problem, then they would likely be as willing to initially trust the campus without the CPS. The only point made in response was that with the loose CPS, there would at least be a guideline about what could be expected.

Finally, following an email thread largely involving Carl Ellison of Intel, there was significant disagreement over the possibility, vulnerability, necessity, and desirability of a key escrow service for document encryption as well as of encryption itself. As an alternative to key escrow, Eric suggested that vital documents that need to be encrypted should be encrypted twice, separately, by different people using different keys. A tragic story was offered about a late security expert who had heavily encrypted his entire hard drive to the point it had to be wiped and any data useful to the company was lost. The loss of the data could have been avoided if the key (in this case, a password) had been escrowed, so there are more eventualities than loss of key that must be dealt with.

Jeff maintains that the fundamental problem with key escrow is that the key repository forms a gigantic target for "crackers of both the technical and legal kind." The protection of this repository can be as arbitrarily tight as desired, but as long as there is a mechanism to legitimately recover data, there will be mechanisms to abuse this process. The risk of failure is too great when a single mechanism exists to guard so much information. Jeff's greatest fear is of legal attacks for which there is little effective defense. Information which may be needed for business purposes is inherently vulnerable to legal injunction.

Alternatives to encryption and key escrow are available within some security models. IPsec, SSL, and SSH tunnels send signed email through secure channels, addressing eavesdropping on the wire, but with these solutions, when data is stored on a POP/IMAP server, it is no longer encrypted, as it would be with S/MIME. The implementation of S/MIME in some current applications, such as Microsoft Outlook, is not well developed, limiting the effectiveness of some approaches. Other applications have multiple vulnerabilities and errors in implementation that make long-term storage of keys for S/MIME and other purposes very difficult. Jeff believes the best solution is that the public key should not be used for long-term storage, trumping the whole issue about key escrow and placing it in a different realm, making the user responsible. Email should be received, decrypted, and then subsequently encrypted again with an appropriate storage key.
Action Items

* [AI] Judith will ensure that CREN's profile is reviewed by HEPKI-TAG to ensure it is consistent with accepted practices.
* [AI] Whether this extension could be added without the private key of the requesting certificate was to be posed to Jeff.
* [AI] Judith will look at the exact wording of the draft policy to identify the ripple effect of revocation.
* [AI] 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.
* [AI] 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.
* [AI] The usability study's results will be forwarded to the list.
* [AI] The draft document already created for the J-STOR pilot will be mailed to the list by Judith.