August 15, 2001
Attendees

* Jim Jokl (chair) - Virginia
* Neal McBurnett
* Ed Feustel - Dartmouth
* Bob Brentrup - Dartmouth
* Eric Norman - Wisconsin
* Renee Frost - Michigan/Internet2
* Chris Misra - Massachusetts
* Michelle Gildea - CREN
* Judith Boettcher - CREN
* David Wasley - UCOP
* Bob Morgan - Washington
* Ben Chinowsky (scribe) - Internet2

Discussion

The call opened with a discussion of the new Microsoft Root Certificate Program (http://www.microsoft.com/TechNet/itsolutions/security/news/rootcert.asp). Michelle noted that while WebTrust, to which Microsoft has delegated CA certification (see http://www.webtrust.org/certauth.htm), will charge less for this service than the $250,000 that Microsoft was charging, the cost is likely to still be significant. Judith asked what people thought of the idea of downloading a list of roots that have been signed as a list, rather than individually; though there where no general objections to this way of doing things, Bob Morgan pointed out that the fact that it's a Microsoft service is likely to bother some people. The cert trust list update function is something that could have been made separable from the operating system, but Microsoft implements it with Windows Update.

The minutes of the previous call were approved without changes. TAG reviewed progress on action items:

[1-August - Ken will contact Todd Needham at Microsoft to a) find out what information Microsoft email clients verify in the root cert and under what conditions they display a warning, and b) try to get a commitment from Microsoft to meet with CSG attendees on September 11.] Ken was not on this call, so there was no update on this item.

[1-August - Ed will contact Netscape to find out what information its email clients verify in the root cert and under what conditions they display a warning.]

Ed has found a Netscape contact who is to provide him with this information. Ed noted that he has also sent mail to Microsoft Research requesting information on issues of concern to people who have many certs. Eric noted that iPlanet makes a lot of technical detail available on its cert server software; in particular he cited the PSM documentation in the manual on plugins for the cert server. [AI] Ed will take a look at the iPlanet documents recommended by Eric, and if necessary will look at the Mozilla PSM code also.

[1-August - Ed will find out what CA software packages are being used on the campuses from which he's received PKI project information, and which of these packages are capable of adding a policy OID.] Still to do. Ed is still gathering contact information; once that's done, he'll send out further requests for information as necessary.

[1-August - TAG will continue discussion of what kind of best practices it should provide for PKI Lite deployment.]

[1-August - TAG will continue its discussion of dc naming in PKI Lite.] See below.

[20-June - All will send Ed a brief description of their campus PKI work, along with the name, email, and phone number of a contact person for that work; Ed will compile a contact list and send it to TAG.]

[20-June - All will provide Jim feedback on the prototype TAG web site (http://middleware.internet2.edu/hepki-tag/).]

[6-June - All will send Jim links to information on their campus PKI work, for the TAG web site.]

[23-May - All will review Jeff's private-key-protection document and send comments to Jeff.]

These request-for-information AIs all still stand. [AI] Ed will review Jeff's private-key-protection document. [AI] Jim will resend Jeff's private-key-protection document to TAG.

The rest of the call was devoted to seeking agreement on what recommendations TAG should make on three PKI Lite issues: what kind of CP should be specified, dc naming in the Subject and Issuer fields, and cert validity periods.

Jim reminded the group that agreement had been reached not to *require* certs to include a policy OID; this leaves the issue of what to *recommend*. There was no conclusive agreement on this issue, but the group leaned toward specifying a policy based on the Rudimentary assurance level as described in the draft HEPKI Campus Certificate Policy (see http://middleware.internet2.edu/certpolicies/). Reference was made to the "18 important pages" of this document; there was interest in condensing these 18 pages into something even simpler, and using that as a PKI Lite policy. The group also discussed the option of specifying a distinction between this Lite policy and a null "PKI Ultralite" "policy", strictly for intracampus use. PKI Ultralite certs would be self-signed roots that would go to no browser beyond the campus. Judith pointed out that the analogy with a campus ID card holds strongly for PKI Ultralite, and David suggested that PKI Ultralite be presented as an optional stage in setting up PKI Lite.

The group agreed to handle the dc naming issue by including a reference to TAG's current statement on the subject (http://middleware.internet2.edu/hepki-tag/dcnaming.html) in the PKI Lite recommendations. This means that the PKI Lite profile will recommend, but not require, dc naming.

There was no agreement on what to recommend for the cert validity period. One issue here is that some people are interested in having certs expire regularly at milestone events in the academic year, so that validity of such certs could be taken to imply currently-affiliated status; authentication via these certs would then be used to authorize access to certain lower-value resources. Bob Morgan characterized doing such "implied authorization" as "an absolute mistake"; in his view, a rigid separation must be maintained between authentication and authorization.
Action Items

* [AI] 15-August - Ed will take a look at the iPlanet documents recommended by Eric, and if necessary will look at the Mozilla PSM code also.
* [AI] 15-August - Ed will review Jeff's private-key-protection document.
* [AI] 15-August - Jim will resend Jeff's private-key-protection document to TAG.
* [AI] 1-August - Ken will contact Todd Needham at Microsoft to a) find out what information Microsoft email clients verify in the root cert and under what conditions they display a warning, and b) try to get a commitment from Microsoft to meet with CSG attendees on September 11.
* [AI] 1-August - Ed will find out what CA software packages are being used on the campuses from which he's received PKI project information, and which of these packages are capable of adding a policy OID.
* [AI] 20-June - All will send Ed a brief description of their campus PKI work, along with the name, email, and phone number of a contact person for that work; Ed will compile a contact list and send it to TAG.
* [AI] 20-June - All will provide Jim feedback on the prototype TAG web site (http://middleware.internet2.edu/hepki-tag/).
* [AI] 6-June - All will send Jim links to information on their campus PKI work, for the TAG web site.
* [AI] 23-May - All will review Jeff's private-key-protection document and send comments to Jeff.