Technical Activities Group Meeting Minutes
HEPKI-TAG Conference Call

August 16, 2000
Attendees

* Jim Jokl (chair) - Virginia
* Mark Poepping - CMU
* Bob Morgan - Washington
* Andy Adamson - Michigan
* Bill Doster - Michigan
* Judith Boettcher - CREN
* Deb Crocker - Alabama
* Eric Norman - Wisconsin
* Patty Gaul - CREN
* Ken Klingenstein - Colorado/Internet2
* Michael Gettes - Georgetown
* David Wasley - UCOP
* Renee Frost - Internet2
* Ben Chinowsky (scribe) - Internet2
* Others joined and left the call at various times.

Discussion

The first topic was Michael's Higher Education Distributed Root Certificate Deployment (heDRCD) document. This document originated in a challenge from Dave Ladd of Microsoft to Michael, to suggest a way Microsoft can support PKI without having to brand a new version of IE every week. Michael has responded and has sent his response to TAG as well, emphasizing that it is a "talking point" and not a finished position statement. Michael gave TAG a brief outline of the ideas in the document. In response to a question, Michael acknowledged that he had not addressed the issue of how the browser is to know what the hostname is. Bob noted that work on cert trust lists is to be published soon in the IETF, and suggested that heDRCD also list requirements or assumptions for deployment. [AI] Over the next two weeks people will mail TAG their comments on the heDRCD document.

The group approved the minutes of the previous meeting; Ben will incorporate some additional information from Neal.

Ken joined the call from the NREN gigabit networking workshop. [AI] Ken will organize a conference call among the people who have submitted cert profiles. [AI] Michael and Jim will submit their cert profiles soon. [AI] Ken will send the group the draft agenda for the CSG meeting.

Most of the call was devoted to an in-depth discussion of dc= naming. Jeff Schiller is opposed to using dc= naming in the CREN cert at this time; should TAG recommend using it in institutionally generated certs? dc= naming could be used in the subject and issuer fields. Bob explained that historically no one has been able to decide what to do with these fields, so they've become junk; dc= naming would make them into real names, i.e. names that refer to real things in the cert's environment. The group reached the following consensus:

*The subject and issuer fields should contain a unique token for the person's name and an indication of the domain in which that name is unique, so that it becomes possible to go to that domain and look up CRLs, directories, etc., for that name in that domain. Wherever the distinguished name (DN) is used, the domain name system (DNS) name should be specified with dc= naming.*

Michael noted that while using URLs instead of dc= naming might be able to address TAG's specific issues (like CRLs), dc= naming ties into other services also, via SRV records in DNS. Instead of coding separately for each resource, dc= naming provides a unified way to point to one location for many resources. David suggested that TAG recommend that to this "handle and a domain in which that handle has meaning", a URL for a (not "the") directory should also be added. Bob pointed out that *both* URLs and dc= naming ought to be available, but right now URLs are the only option. [AI] Bob will further document the nature and virtues of dc= naming.

The dc name in the subject field must be on the far right in normal DNS order (e.g. dc=georgetown, dc=edu); Win2K and other LDAP-based software is built to interpret this particular data structure.

No consensus was reached on a recommendation for the subjectAltName and issuerAltName fields; Bob pointed out that deciding what to do with these fields is harder because there are more kinds of things you can put in them. There was general agreement that the issue here is not what these fields *require* but rather what they *permit*. Jim noted that RFC2459 says software must be able to handle dc= naming, but doesn't mandate its use. Bob suggested that TAG find out if x.509v4 will have changes re subjectAltName.

There was discussion of how comments on TAG's dc= naming recommendation should be solicited. Michael noted that related issues are still under discussion among the Feds. Ken reported that the recommendation expected to come from the NREN workshop is "navigable hierarchies", like DNS. [AI] Jim will get a few people together to write up what's been agreed on about dc= naming, in preparation for sending it out to be vetted.

Michael noted that [Company] wants to know if CREN would be willing to pay $50,000 to put one cert per year in the browser. [AI] Michael will reply to [Company] with a request for the 90%+ discount that is the norm for higher education.

Finally TAG briefly discussed mobility work and private-key best practices. Ken thinks we should push the mobility work harder; Eric is short of time, so Ken offered to work on mobility issues with Eric. Ken and Judith have found much interest in documenting best practices for the protection of private keys. [AI] Judith will discuss private-key BPs with people at the CSG meeting, or bring together a group before then to take on this project.


Action Items

* Over the next two weeks people will mail TAG their comments on the heDRCD document.
* Ken will organize a conference call among the people who have submitted cert profiles.
* Michael and Jim will submit their cert profiles soon.
* Ken will send the group the draft agenda for the CSG meeting.
* Bob will further document the nature and virtues of dc= naming.
* Jim will get a few people together to write up what's been agreed on about dc= naming, in preparation for sending it out to be vetted.
* Michael will reply to [Company] with a request for the 90%+ discount that is the norm for higher education.
* Judith will discuss private-key BPs with people at the CSG meeting, or bring together a group before then to take on this project.