Untitled Document

Technical Activities Group Meeting Minutes
HEPKI-TAG Conference Call

September 26, 2001
Attendees

* Jim Jokl (chair) - Virginia
* Chris Misra - Massachusetts
* Eric Norman - Wisconsin
* Judith Boettcher - CREN
* Bob Morgan - Washington
* Michelle Gildea - CREN
* Bill Doster - Michigan
* Neal McBurnett
* Bob Brentrup - Dartmouth
* Ed Feustel - Dartmouth
* Jeff Schiller - MIT/CREN
* Ellen Vaughan - Internet2
* Ben Chinowsky (scribe) - Internet2

Discussion

The group reviewed progress on action items:

* [29-August - Renee will look into what policies Internet2 is considering for software distributions.] Renee was not on the call, so status is unknown.
* [29-August - Jim will send Renee a CPM document that makes clear that CPM is for worldwide distribution.] Done.
* [29-August - All will look into which of their prospective PKI applications will separate authorization and authentication, and which will conflate them.] Still to do; see PKI Lite cert profile discussion below.
* [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.] Done. While Ed didn't find the information he needs, he noted that he's been able to get both Navigator and IE to download certs from LDAP directories. Eric noted that he's been able to get the Tumbleweed plugin to work.
* [15-August - Ed will review Jeff's private-key-protection document.] Redundant with "All will review..." action item below.
* [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.
* [6-June - All will send Jim links to information on their campus PKI work, for the TAG web site.] Ongoing.
* [23-May - All will review Jeff's private-key-protection document and send comments to Jeff.] Still to do.

Much of the call was devoted to nailing down details of the PKI Lite cert profile.

Jim reviewed TAG's August 29 decision on the cert policy field: there will be an OID, and it will point to a short document stating that that the CA follows "generally accepted practices" in higher education. There was general approval. Ed noted that this squares with PAG's understanding. Eric noted that a new S/MIME RFC formalizes policy statements so that cert verification can be automated; these policy statements include signed hashes so the verifier can prove they used the statement that was in effect at the time the verification was done. Jim noted that the policy OID field is multivalued, so TAG's decision means that one of the values for each participant will be the same OID, referring to the ultra-minimal PKI Lite policy.

Several factors were identified as worthy of consideration in choosing a validity period. Ed pointed out that the validity period you want depends on if you're paying per cert or per verification. He also noted that the validity period has much more to do with authorization than with authentication, as authorization information is likely to change much more often than authentication information. The group agreed that authentication and authorization should be kept separate as much as possible. There was also consensus that a long validity period is most convenient for S/MIME, where short validity periods are better for other applications. Jeff said that in his experience having certs all expire on the same day is a non-problem; people usually don't get certs until they need them, so spikes in cert issuance are driven by need-creating events like registration, not by expiration. MIT doesn't encourage people to get certs before they are needed, because that would mean more forgotten passwords; to avoid this problem, Ed suggested that TAG's advice on the validity period should include immediately either using the cert or installing it in the browser. The group agreed to recommend 13 months (for year-long cycles, plus a grace period) as the maximum validity, and to also include JSTOR's case for a one-year maximum, and an explanation of the issues discussed above.

The profile will include some information on how revocation relates to authentication and authorization, but not recommend any particular rules for when certs should be revoked.

Email addresses will be included in both Subject and SubjectAltName; while this has been deprecated for the Subject field, older applications may still need it.

The profile will make no recommendation for IssuerAltName.

The profile will include a URI for the CPS.

With these decisions, the PKI Lite cert profile is complete; there was much rejoicing. [AI] Jim will write up the final version of the PKI Lite cert profile, including annotations based on TAG's discussions.

Finally the group discussed an assortment of next steps for PKI Lite.

[AI] Ellen will work with Renee on the issue of which OID to use (CREN has volunteered one), and get back to Judith to plan further.

There was a short discussion of how best to make use of the existing CREN infrastructure. Jeff argued against the idea of CREN setting up a separate PKI Lite branch of its hierarchy, as this would involve CREN telling the universities what policies to follow. Ed raised the question, what then is a university that gets a cert from CREN agreeing to do?, and Judith replied that more discussion in the HEPKI community would be needed to flesh out the idea of "generally accepted practices". Ed suggested using the CREN framework document as a starting point for this discussion; [AI] Ed will send out the URL for the CREN framework document. Jeff quoted the new profile document (version 8) to the effect that the policy of a CA cert does not constrain the policy of a subordinate CA. Ed's understanding is the opposite; [AI] Ed will dig into the new profile document to resolve his disagreement with Jeff about constraints on policies of subordinate CAs.

[AI] Eric will put his demo cert issuer on the Internet2 demo machine. Judith noted that Frank Grewe has a demo CA at CREN; [AI] Judith will see if Frank Grewe or Ron Hutchins can get TAG some CREN- and institution-signed user certs to use on the demo site to practice following chains. [AI] Jeff will look into getting user certs from MIT for the demo site.

Eric noted that incompatibility of encryption algorithms will be a problem for S/MIME. [AI] Eric and Jim will experiment with using S/MIME clients to exchange encryption capabilities.

Eric also pointed out that many mail clients are badly broken in that when they detect a broken signature, they show nothing; Jim noted that finding out things like this is a good reason to do the PKI Lite S/MIME pilot.
Action Items

* [AI] 26-September - Jim will write up the final version of the PKI Lite cert profile, including annotations based on TAG's discussions.
* [AI] 26-September - Ellen will work with Renee on the issue of which OID to use (CREN has volunteered one), and get back to Judith to plan further.
* [AI] 26-September - Ed will send out the URL for the CREN framework document.
* [AI] 26-September - Ed will dig into the new profile document to resolve his disagreement with Jeff about constraints on policies of subordinate CAs.
* [AI] 26-September - Eric will put his demo cert issuer on the Internet2 demo machine.
* [AI] 26-September - Judith will see if Frank Grewe or Ron Hutchins can get TAG some CREN- and institution-signed user certs to use on the demo site to practice following chains.
* [AI] 20-June-2001 - All will provide Jim feedback on the prototype TAG web site (http://middleware.internet2.edu/hepki-tag/) by Wed. June 27, with a view to getting the site ready to link in by Fri. June 29.
* [AI] 26-September - Jeff will look into getting user certs from MIT for the demo site.
* [AI] 26-September - Eric and Jim will experiment with using S/MIME clients to exchange encryption capabilities.
* [AI] 29-August - Renee will look into what policies Internet2 is considering for software distributions.
* [AI] 29-August - All will look into which of their prospective PKI applications will separate authorization and authentication, and which will conflate them.
* [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] 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.