December 6, 2000
Attendees

* Jim Jokl (chair) - Virginia
* Scott Fullerton - Wisconsin
* Eric Norman - Wisconsin
* Keith Hazelton - Wisconsin
* Neal McBurnett - Avaya
* Michael Gettes - Georgetown
* Deb Crocker - Alabama
* Mark Poepping - Carnegie Mellon
* Bob Morgan - Washington
* Judith Boettcher - CREN
* David Wasley - UCOP
* Ken Klingenstein - Colorado/Internet2
* Jeff Schiller - MIT/CREN
* Ben Chinowsky (scribe) - Internet2
* Others joined and left the call at various times.

Discussion

After approving the minutes of the previous meeting, TAG resumed its discussion of dc naming. In addition to disagreement about where in the DN to place the dc components, there was some confusion due to the existence of two different ways of describing this placement -- right/left vs. most significant/least significant -- and two different ways of mapping between them. IETF documents and many recent PKI documents write DNs with the most significant components on the right, while some older documents put the most significant components on the left. It was agreed that TAG will use the IETF-style, most-significant-on-the-right notation. It was noted that regardless of how DNs are written for human readers, the use of ASN.1 makes them unambiguous as far as computers are concerned. Jeff's central objection to the proposal of draft-ietf-ldapext-locate-04.txt is its inflexibility: while, in Jeff's view, there are situations in which the dc components should be placed together at the most-significant end of the DN, situations in which the dc components should be placed together at the least-significant end of the DN, and situations in which the dc components should be interspersed with the corresponding civil-naming components, draft-ietf-ldapext-locate-04.txt requires that in all cases the dc components be placed together at the most-significant end of the DN. Jeff is going to recommend that this requirement be removed from draft-ietf-ldapext-locate-04.txt; Bob has given his co-authors on this document a heads-up on this, and agrees that the most-significant requirement needs justification.

Bob noted that a current Internet-Draft (ftp://ftp.normos.org/ietf/internet-drafts/draft-ietf-pkix-new-part1-03.txt), among other changes to RFC 2459, proposes using an extension field (Subject Information Access) to get further information about a cert via an LDAP or other URL. This raises the same security issue that name constraints are meant to deal with.

Eric recommended that certs contain information that helps users verify thatthey are actually talking to the server the cert is pointing them to.

After further discussion of the best-practices-recommending rather than standards-setting role of TAG, the group discussed security issues inherent in using DNS lookups. Bob noted that while both DNS/IP lookups and SRV lookups can be protected with SSL, protecting SRV lookups would be more complicated and therefore harder. It was agreed to table the dc naming issue until after next week's IETF meeting. [AI] Bob and Jeff will meet at IETF to further discuss dc naming.

There was a brief review of the recent Ed/Fed meeting; although no new milestones have been reached, both sides continue to make progress. Lack of budget is slowing the FBCA work; it is hoped that a Dec. 8 budget meeting will resolve this. TAG attendees were introduced to Judy Spencer, who will be taking over from Rich Guida in January.

Next was a discussion of profile convergence work. It was agreed that profiles should not be put in CPs, as doing so would lead to a proliferation of CPs. There was general agreement that, among the issues the cert-profiles group has identified, dc naming is the only really big one, so that convergence should now be fairly easy to reach. The cert-profiles group agreed to continue meeting to resolve the remaining issues, focusing on identity certs and using David and Mine's template as a starting point. The cert-profiles group will try to resolve the easier issues via email, then address the harder issues in conference calls early next year. [AI] Ken will email the cert-profiles group, polling them on which fields they think represent the easier problems.

Jim concluded the meeting with a plea for information for the TAG web site, and in particular for further work on the proposed survey of PKI activity at HEPKI schools. [AI] Jim will put a more detailed discussion of TAG web site content on the agenda for the next call.
Action Items

* [AI] Bob and Jeff will meet at IETF to further discuss dc naming.
* [AI] Ken will email the cert-profiles group, polling them on which fields they think represent the easier problems.
* [AI] Jim will put a more detailed discussion of TAG web site content on the agenda for the next call.