October 25, 2000
Attendees

* Jim Jokl (chair) - Virginia
* Ken Klingenstein - Colorado/Internet2
* Renee Frost - Michigan/Internet2
* Michael Gettes - Georgetown
* Eric Norman - Wisconsin
* Patty Gaul - CREN
* Frank Grewe - Minnesota
* Neal McBurnett - Avaya
* David Wasley - UCOP
* Bob Morgan - Washington
* Ben Chinowsky (scribe) - Internet2

Discussion

After approval of the minutes, the group reviewed points 5, 6 and 8 of Ken's summary of the findings of the TAG cert profiles committee:

Certificate Profile Similarities and Differences
10/24/00

Version 3 certificates (mark the version field with a 2).
Keep the contents simple and generally non-volatile; no one is doing CRLs yet.
Signing algorithms: either RSA with MD5 or RSA with SHA-1.
Concerns with how FERPA addresses contents of a cert.
Have an indicator of the strength of the identification process. Options include an explicit extension field or a policy OID that contains ID process.
Inclusion of some domain component information within the payload. Options include within Subject name, within Issuer name, within CRL distribution point extension, and within a URL extension.
Key usage extension included? Not all sites do; those that do may mark it as critical.
Little use of constraint extensions (basic, name, policy).
Validity periods range from per-session to one year. For longer term, having a uniform expiration date (e.g. first day of next semester) to avoid CRL. For longer term intended for external use, use a starting date that avoids time zone issues (e.g. set starting date to one day prior to issue).
Inclusion of serial number in issuing CA, to deal with migration from experimental to production and subsequent changes.
Desire to build a minimal number of profiles within the community.
Item #5 - Indicating the strength of the ID process.
Four options were identified here:
separate OIDs for different strengths of identity, with each OID pointing to a separate CP;
separate OIDs for different strengths of identity, with each OID pointing to a different section of a single CP;
using an explicit extension field; and
using a separate CA for each security level, and coding the name of the CA that maps to the level of assurance being used into the issuer field.
Item #6 - Domain component information.
While there was consensus that the domain component information needs to be in the cert somewhere, no fewer than six different suggestions have been made for where to put it: Subject name, Issuer name, Subject Alternative name, Issuer Alternative name, a CRL distribution point extension, and a URL extension. David noted that while domain components are a good way to identify name context, finding the attribute database is a separate issue. Do you infer its location from the CA domain context, from the Subject, or in some other way? California has added a URL extension for this purpose; they have found this to be a good solution due to its flexibility. There was general agreement that even if TAG does not recommend a specific location for the domain component information, its recommendations should stress the importance of putting in something that helps you find directories.
Item #8 - Name constraint extensions.
There was a long discussion of name constraints, why we didn't see much use of these constraints in the existing profiles, and potential uses of name constraints for applications such as the Grid. Name constraints are used to limit the legal name space for the Subject and Subject Alternative names in subsequent certificates in the certification path. Topics discussed included:

Questions on which PKI software actually supports name constraints. Michael has heard that the Whistler code from Microsoft and the Entrust suite are the only ones presently obeying name constraints.
If little software supports name constraints, is it a tool that we can rely on in the near future?
Questions on the range of a Subject name. Is it safe to assume that the Subject is relative to the Issuer, or must these be treated independently?
[AI] Eric will find out what the X.509 spec says about name constraint extensions.
Finally, Ken noted that certs-profiles issues will be discussed in the TAG report in Atlanta next week. [AI] All will send the list feedback on those of today's agenda items (most of them) that were not covered in today's discussion.

Action Items

* [AI] Eric will find out what the X.509 spec says about name constraint extensions.
* [AI] All will send the list feedback on those of today's agenda items (most of them) that were not covered in today's discussion.