*HEPKI-TAG Conference Call* May 31, 2006

*HEPKI-TAG Conference Call*
May 31, 2006

*Attendees*
Jim Jokl (chair) - Virginia
David Wasley - independent
Nathan Faut - KPMG
Jeff Schiller - MIT
Eric Norman - Wisconsin
Renee Frost - Michigan/Internet2
Neal McBurnett - Internet2
John Krienke - Internet2
Ben Chinowsky (scribe) - Internet2

*Action Items*(new)

[AI] Eric will email Scott Rea for details on differences in browsers' cert-importing behavior, and do some experimenting.
[AI] Jim will incorporate the group's feedback into the next draft of the CA requirements document, and add a paragraph or two on the intent of the project, the background expected of the deployer, and how the package might be used for both pre-production and production.
[AI] All will send Jim their thoughts on the following sections of http://middleware.internet2.edu/hepki-tag/new/ca-req-2.html:
- Section 4 - what needs to be logged?
- Section 5b - what information in the cert request should be validated, and
what information needs to be returned to validate it?
- Section 7c - what apps should be included?

(from previous calls)
[AI] All will ask their contacts what material their schools would find most useful in a PKI implementers workshop.
[AI] David will follow up on SAFE's open-source signing work.
[AI] All will send URLs for CA software (open-source or not) to TAG.
[AI] Eric will let TAG know when Ron DiNapoli's work on Aladdin eTokens on Macintosh is available for the group to look at.
[AI] All will look at http://www.gridpma.org for materials for the CA Audit project to point to or extract from.
[AI] Bob will send out pointers on UW's experience with the Federal Credential Assessment Framework (CAF).
[AI] All who can test the Eudora S/MIME plugin, or find others to do so, will contact Jim.
[AI] Jim will expand the signing-tools matrix with columns on APIs and scripting tools; multiple signatures (parallel vs. stacked); and whether or not the tool lets you add a trust anchor.
[AI] All who have time to investigate one or more of the signing tools at http://middleware.internet2.edu/hepki-tag/new/signing4.html will contact Jim.
[AI] Jim will continue looking at PKI Lite cert profiles for Rice's code-signing application.
[AI] Eric will call Mozilla's attention to the fact that they don't support the standards needed to recognize trust anchors on tokens, and nudge them to do something about it.
[AI] Eric will continue seeking feedback on his Top 10 lists, especially from HCISec.
[AI] Jim will get an OID for PKI Lite from MACE.
[AI] Mark will ask Jed Dobson for more information on OSG.
[AI] David will look at some of the products listed at http://middleware.internet2.edu/hepki-tag/new/signing4.html in the light of the list of questions there.
[AI] Neal will continue looking at OpenOffice, and Jim will look at eLock.
[AI] Jim will send the list more information on the Acrobat transcript-signing work at U. of Chicago.
[AI] Jim will draft a discussion of the pros and cons of hierarchical and flat campus PKIs for discussion on a future call.
[AI] All will send Jim further suggestions for TAG projects.
[AI] Jim will send mail to people who have expressed interest in various possible areas of work for TAG, and work toward finding a focus for the group.

*Discussion*
Neal noted that Scott Rea has documented different default behaviors that browsers display when importing certs; for example, Internet Explorer will automatically trust the root, where others don't. Eric volunteered to experiment further with this. [AI] Eric will email Scott Rea for details on differences in browsers' cert-importing behavior, and do some experimenting. Eric suggested producing a CD that would install the USHER root in any browser; Jim noted the "Two mechanisms for installing a root certificate into Internet Explorer" material at http://pkidev.internet2.edu/. Neal noted Jeff Schiller's point that the cert-import process needs to clearly tell the user when the import is finished; Jeff has done some work on ways to get different browsers to leave users on a helpful page at the end of the process.

Most of the call was spent reviewing the latest CA requirements document (http://middleware.internet2.edu/hepki-tag/new/ca-req-2.html). Eric observed that the requirements list makes the packaged CA a tool for using PKI, but not a tool for teaching the basics. There was general agreement that teaching PKI is, and should remain, out of scope for the project. There was also general agreement that a user deployment guide will be needed. [AI] Jim will incorporate the group's feedback into the next draft of the CA requirements document, and add a paragraph or two on the intent of the project, the background expected of the deployer, and how the package might be used for both pre-production and production.

[AI] All will send Jim their thoughts on the following sections of http://middleware.internet2.edu/hepki-tag/new/ca-req-2.html:
- Section 4 - what needs to be logged?
- Section 5b - what information in the cert request should be validated, and
what information needs to be returned to validate it?
- Section 7c - what apps should be included?

Jim noted that he's confident that funding for the packaged CA project will be available, provided that the requirements are straightforward to implement. If implementation becomes a years-long project, funding will likely not be available.

Two other issues were suggested for inclusion in the requirements document: the languages to be used to implement callouts, and what platforms should be supported. These issues came up at the end of the call, and no agreement was reached on if or how to address them.