Technical Activities Group Meeting Minutes
HEPKI-PAG Conference Call

February 14, 2001
Attendees

* Jim Jokl (chair) - Virginia
* Michael Gettes - Georgetown
* Neal McBurnett - Avaya
* Eric Norman - Wisconsin
* Bob James - Pitt
* Renee Frost - Michigan/Internet2
* Judith Boettcher - CREN
* Deb Crocker - Alabama
* Jeff Schiller - MIT/CREN
* Bob Morgan - Washington
* Bob Brentrup - Dartmouth
* Ben Chinowsky (scribe) - Internet2

Discussion

After approving the minutes, TAG reviewed progress on the action items from the last call.

1. Kevin and Renee will set up the TAG-Mobility conference calls. - Done; the TAG-Mobility calls are scheduled for every other Thursday at 1:00 PM EST, starting on February 22.
2. Bob Morgan will forward to the list any additional pointers that he has on XML digital signatures. - Bob is about to go on vacation; he'll do this when he gets back in a couple of weeks.
3. Ken will work to organize the certificate profile convergence process for the generic identity certificate. - The cert profile convergence calls are scheduled for every other Thursday at 1:00 PM EST.
4. browser usability document: David will attempt to contact the right people at iPlanet. - No update, as David was not on the call. Jim will contact Michael about potential Microsoft contacts. - Michael has provided Jim with a list drawn from his Guida/Burr Microsoft contacts.
5. The group decided to finish the poll of TAG institutions about their initially planned PKI applications. Schools actively working on PKI deployments and willing to contribute should send their initial application list to Jim for incorporation in the spreadsheet. - Jim noted that he has received two such lists since the last call, and that he would love to see more.
6. Renee will send a list of people on the mobility-group list to the general TAG list. - Done.

Most of the call was devoted to a discussion of Michael's Higher Education Distributed Root Certificate Deployment document ( http://www.georgetown.edu/giia/internet2/heDRCD.html ), and alternative solutions to the fundamental trust-bootstrapping questions it addresses.

The group identified three problems with the heDRCD proposal:

1. It depends on DNS, which isn't secure and isn't likely to become secure any time soon.
2. It depends on vendors such as VeriSign and Thawte signing the root-cert packages being distributed; the vendors' willingness to do this is questionable at best.
3. It depends on being able to search for SRV records in the top-level .edu domain, and .edu is currently being managed in a less-than-spectacularly-efficient manner. (The force of this criticism was blunted somewhat by Michael's and Ken's observation that the long-awaited takeover of .edu by EDUCAUSE appears to be getting closer.)

Jeff suggested that Internet2 address these problems by making an arrangement with Akamai to run a server that would deliver the heDRCD certs package over SSL. This would require defining two new MIME types, for the certs package and a hash of it, but it would get rid of heDRCD's dependence on cert vendors and DNS.

Jeff also suggested a different approach: that CREN set up an SSL-protected repository for self-signed institutional CA certs. This approach has the virtue of simplicity; Eric volunteered to write "the six lines of perl code required to do this." Two flavors of this proposal were discussed. Bob M. proposed simply making the certs available, together with instructions along the lines of "here are institutional certs, download and use them", and suggested that this might be as effective in promoting institutional interoperability as CREN's program of signing campus CA certs. (The assurance process that a campus would have to go through to get its self-signed cert into the CREN repository would be the same as the assurance process that CREN uses to certify campus CA certs.) Neal objected that the presence of the institutional certs on the CREN server, SSL-protected or not, would not be a sufficient guarantee of their trustworthiness; he proposed that instead CREN sign them with its own self-signed root cert, and distribute that root cert to the users. Neal's variant of the CREN-repository approach would require users to check the fingerprint of the CREN root cert against an out-of-band record, most likely a paper document handed to the users when they sign up for an account; Jeff and Bob M. expressed strong pessimism about student compliance with even minimal procedures of this type. Another related usability issue is the process of downloading the CREN root cert; Judith described this as "fairly straightforward". [AI] All will download the CREN root cert and give Judith feedback on the process.

While the group did not reach consensus that the heDRCD approach should be discarded, there was agreement that the CREN-repository approach could provide most of the benefits of heDRCD. It was also agreed that browser modifications would be required to automate this process; this is something that TAG could write up and deliver to Microsoft, in response to the request for input that prompted heDRCD in the first place. It was noted that Microsoft is going forward with related browser user-interface work.

Finally, the group reviewed the latest version of the draft TAG dc naming recommendation ( http://pluto.itc.Virginia.EDU/~jaj/dcnaming.html ). The group confirmed its decision to recommend that, where available, pointers provided in the cert should be preferred over pointers obtained from DNS via dc naming. It was agreed that standardization of extensions such as authorityInfoAccess could provide a solution superior both to the institution-specific extensions now used and to dc naming, and that the document should include a commitment from TAG to track the progress of such developments.


Action Items

* [AI] All will download the CREN root cert and give Judith feedback on the process.