Technical Activities Group Meeting Minutes
HEPKI-TAG Conference Call

August 30, 2000
Attendees

* Jim Jokl (chair) - Virginia
* Jeff Schiller - MIT/CREN
* Judith Boettcher - CREN
* Michael Gettes - Georgetown
* Neal McBurnett - Avaya
* Bob Morgan - Washington
* Eric Norman - Wisconsin
* Ken Klingenstein - Colorado/Internet2
* Renee Frost - Michigan/Internet2
* David Wasley - UCOP
* Ben Chinowsky (scribe) - Internet2
* Others joined and left the call at various times.

Discussion

The meeting opened with a review of the minutes from the previous meeting. There were no corrections; if none are received by Friday, September 1, the minutes will be posted as is.

Much of the call was devoted to discussion of issues raised by Michael's Higher Education Distributed Root Certificate Deployment (heDRCD) document. Michael noted that a conversation with Neal had revealed "fundamental issues" concerning his approach; Michael realizes that the document needs work. Neal elaborated: as things stand now, getting root certs into browsers requires decisionmaking on the part of users, which in turn necessitates a significant amount of user education and support; heDRCD proposes to substitute automatic methods, but Neal is uncomfortable with the insecure means (DNS & IP routing) suggested. Neal is trying to find a more secure method, such as Kerberos, to accomplish automatic distributed deployment. Jeff expressed the opinion that distributed root cert deployment is "the toughest problem" in making PKI work, and that the hardest aspect of this problem is not the secure distribution of the real cert, but stopping users from installing a bogus cert. People who are willing to read and follow the instructions can verify the authenticity of the cert, but getting people to do this is a highly non-trivial task. Jeff observed that there has already been an attack against Netscape involving "replacing the cert in flight" during browser download. Ensuring that users are not tricked into installing a bogus cert is an example of the "leap of faith" problem. The user periodically needs to go through the process of establishing a trusted computing base on their computer, and in the process the user inevitably needs or wants to trust that there aren't any trojans or risky configurations in (for example) the hardware, firmware, or pre-installed software. Jeff noted that while these dangers cannot be eliminated, they can be minimized by designing software and infrastructures so that "if someone plays games with us, that will be detected quickly".

Michael asked the group if the heDRCD approach might actually make things worse. He noted that as the heDRCD approach depends on DNS, there is no real trust base; the idea is to keep reaching upward through the DNS hierarchy until you find a host which offers to provide a cert signed by one of the top 12 CAs. Jeff strongly recommended staying away from dependence on corporations, noting that a big problem in the history of PKI in higher education is that "whenever we create gods, we create reptiles". Jeff pointed out that adding complexity reduces reliability; the issues with heDRCD are aspects of the "trusted software on the client problem", and there is no 100% reliable solution without the use of trusted client software. Jeff suggested working with the vendors to get modifications made to the browsers, such that if the browser detects that a cert has been replaced, it will notify the user and prompt for appropriate action. David suggested modifying the heDRCD framework by replacing DNS tree-climbing with building in the canonical dozen certs and providing locations from which to download others. This brought the discussion back to the issue of how to get non-technical users to make the right choices when prompted to make decisions about downloading and checking root certs. This involves instilling the appropriate degree of concern in users, giving them clear and reliable guidelines for what to do next, and working to ensure that when the inevitable mistakes are made, the resulting problems are detected early and mitigated effectively. No consensus was reached on the issue of how much additional complexity heDRCD would introduce, or on the viability of the approach as a whole. [AI] Michael will resend heDRCD to TAG, and TAG will discuss the document further via email and in the next call. [AI] Judith will see Jeff at a September 8 meeting, and will prompt him to read heDRCD. [AI] Neal will further discuss heDRCD with Ken, Jeff, and Michael, and will write a short document on bootstrapping a trust relationship.

The discussion then moved on to Jim's summary of the group's consensus on dc= naming. There was general agreement that Jim had accurately summed up the consensus. Ken pointed out that in the next two months there will be three major opportunities for TAG to share the results of its work, and Judith noted that people appreciate being made aware of problems even if no solutions are provided. It was agreed that TAG should start posting its recommendations on the HEPKI site. [AI] Ken will have the Europeans vet Jim's dc= naming draft, and will have it posted on the HEPKI site for wider review. [AI] Jim will consider incorporating a note from Bob into the dc= naming document, and will confer with Bob on the result. TAG agreed that in addition to being posted on the Web, the dc= naming document should be emailed to the CA list and others for their review.

Next was a discussion of expanding the content of the TAG web site. Jim has put together a list of things to add, with a focus on providing background and recommendations for schools looking for guidance getting started with PKI; he asked the group for further suggestions. It quickly became apparent that while TAG may not have all the answers, it does have an abundance of well-documented questions; there was great interest in capitalizing on this strength. Suggestions for content included: links to other PKI sites, an introduction to issues involved in choosing between open-source and commercial solutions, best practices for private-key protection, information on hardware tokens and mobility, recommendations on dc= naming and other implementation specifics, a directories FAQ, and David's documents on certs types and certs in browsers. It was agreed that TAG needs a web page separate from the general HEPKI page. [AI] Ken will write a PKI roadmap to go on the main TAG page. [AI] Jim will produce a mockup of the expanded TAG web site. [AI] TAG members will send links and other suggested TAG web site content to the list.

Finally, Judith notified the group that she would be at a PKI symposium in Europe during the EDUCAUSE conference. She will be presenting, and will report back from this meeting on the TAG call in four weeks.


Action Items

* Michael will resend heDRCD to TAG, and TAG will discuss the document further via email and in the next call.
* Judith will see Jeff at a September 8 meeting, and will prompt him to read heDRCD.
* Neal will further discuss heDRCD with Ken, Jeff, and Michael, and will write a short document on bootstrapping a trust relationship.
* Ken will have the Europeans vet Jim's dc= naming draft, and will have it posted on the HEPKI site for wider review.
* Jim will consider incorporating a note from Bob into the dc= naming document, and will confer with Bob on the result.
* Ken will write a PKI roadmap to go on the main TAG page.
* Jim will produce a mockup of the expanded TAG web site.
* TAG members will send links and other suggested TAG web site content to the list.