November 22, 2000
Attendees

* Jim Jokl (chair) - Virginia
* Bob James - Pitt
* Renee Frost - Michigan/Internet2
* Scott Fullerton - Wisconsin
* Keith Hazelton - Wisconsin
* Eric Norman - Wisconsin
* Jeff Schiller - MIT/CREN
* Bob Morgan - Washington
* Ariel Glenn - Columbia
* Neal McBurnett - Avaya
* David Wasley - UCOP
* Ken Klingenstein - Colorado/Internet2
* Ben Chinowsky (scribe) - Internet2
* Others joined and left the call at various times.

Discussion

After reviewing the minutes and action items from the last meeting, TAG devoted the rest of the call to a long discussion of dc naming. While the group did not reach agreement on what recommendation to make, it did succeed in clarifying the pros and cons of three different approaches to the problem of how to provide a way for a relying party to find out more information about the Subject and Issuer of a certificate.
1) Use dc naming in the Subject and Issuer fields.

* http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-04.txt sets out the details of this approach. In mail sent to TAG during this call, coauthor Bob Morgan notes that "The point at the heart of my argument on this issue is that the Subject (or subjectAltName) of a certificate should be an identifier that the relying party can use to find out more information about the real-world subject of the cert (and all the same stuff here applies to Issuer/issuerAlt, too). It is undeniable that this intention is at the core of the design of X.509: subjects are Directory Names so you can find the directory entry with that name." Another argument for this approach is that in the directories community dc naming is already (and increasingly) considered best practice; in particular, Win2000 and OpenLDAP use it, and iPlanet is expected to adopt dc naming also.
* An objection raised to the draft-ietf-ldapext-locate-04.txt proposal was that its specification that the dc components be placed at the top of the DN is "onerous", violating the IETF principle of being "strict in what you generate and forgiving in what you accept". It was suggested that instead the placement of the dc's within the DN not be specified, and that the whole DN be scanned for these components. Against this approach it was argued that not specifying the location of the dc's runs counter to the way things are usually done in the directories world, thereby raising difficult questions.

2) Use domain names in the subjectAltName and issuerAltName fields.

The advantage of this approach is that, as the DNS name is not part of a DN, the issue of where to place the DNS name within the field becomes less important. It was also suggested that the DNS name could be stored as a single string rather than being broken up into dc's. While this is not likely to create any serious problems, it would break symmetry with RFC 2247, which draft-ietf-ldapext-locate-04.txt is intended to complement.

3) Use an explicit LDAP URL in a cert extension field.

This could be done either by adopting an existing extension field or by creating one specifically for this purpose.

* The RFC 2459-defined authorityInformationAccess field has been suggested as a location for an LDAP URL.
* David Wasley noted that the University of California uses a custom extension for this purpose.

Combining these approaches is also a possibility, and there was consensus that an explicit directory URL should take precedence over a directory reference via a DNS name.

It was also noted that establishing the norm of having a DNS name within a DN addresses the more general problem of how to find a directory when given only a DN (as vs. an entire cert), as with see-also directory references.

Action Items

* The group will consider the relative merits of the three approaches to dc naming discussed in today's call, and will continue the discussion in email and on the next call.