Technical Activities Group Meeting Minutes
HEPKI TAG Conference Call

January 29, 2003
Attendees

* Renee Frost, Internet2
* Neal McBurnett, Internet2
* David Wasley, UCOP
* Eric Norman, U. Wisconsin
* Bob Morgan, U. Washington
* Jim Jokl, U. Virginia
* Jeanette Fielden, Internet2

Discussion

Eric has created a process to install a group of root certificates at the same time from a single transportable file. It works with both servers and clients for IE, Netscape, and Mozilla. You only have to go through the process once, not for each certificate being installed. The certificate used to sign all the other certificates being installed goes into the trusted root store. All others install as intermediate certificates. This would be suitable for any enterprise or campus application where you could replace all the existing certificates and in effect say: "Here are all the certificates we endorse."
[AI] Eric will send a demo to the list when he gets further on this.

Private Key protection: Jeff couldn't be on the call but he is finishing the draft of his document and will add text about hardware protection.
[AI] Eric will send a demo to the list when he gets further on this.
[AI] Jim will e-mail Dartmouth to see if they are doing private key protection for their CA.

S/MIME challenges list: The goal is to document them and generate ideas for the S/MIME group.

1. No CA on campus. Schools do not have CA's ready and want to get that done before tackling S/MIME
2. Lack of support and clients. At Wisconsin the biggest issue was lack of support in Eudora so users had to switch to a different e-mail client to do S/MIME. Mulberry, and some flavors of UNIX/Linux mailers also don't have support. Pine does but it is not part of the standard distribution. There is a table on the website which tracks client with major usage that support S/MIME though it has not been updated.
3. Generic issue of encryption and escrow - recovering encrypted documents because users lost their key. The critical notion is that business documents, especially those that are subject to legal discovery and the Freedom of Information Act (FOIA, need to be available regardless of whether the person with the key is available or not. David talked about the sensitive business documents/FOIA issue. He chairs a secure messaging group at UCOP and there is a great deal of interest from the medical schools in secure e-mail. The proposal is to issue an identity cert for which the key usage bit for encryption is not set and tell people that's how they identify themselves to applications, for digital signatures etc. A second cert is issued, the S/MIME cert, where signing and encryption are set so the e-mail address is in the all subject name. The key pair is generated and the keys are escrowed, to ensure retrieval if it's ever required. UCOP is concerned about students inadvertently revealing their name and association with the university by using the identity cert with an outside agency so they're intentionally a pseudonymous identifier with no identity information. In the subject name is UID=long integer. If you are authorized you can use the UID to retrieve person information.
4. How do you find someone else's LDAP directory? Some sort of heuristic or standard to find the directory where the potential recipient's certificate is available in an inter-institutional setting is needed.
5. The bridge issue of certifying the certificate.

There is also a related overall education issue regarding what users think security is. At Wisconsin there have been efforts to encourage people to use SSL connections to the IMAP and POP3 servers on the campus mail system. People have used the phrase "this is securing electronic mail" in the effort; so many people are under the impression that means the e-mail itself, not the connection, is secure. So there needs to be a clear distinction on what kind of security is being discussed.

There was discussion of whether it's true when you receive a signed message and later want to send an encrypted mail back that you can do so without having to go and retrieve the encryption cert. If a single certificate is used for both signing and encryption it works fine. It is not clear that sending a signed message is sufficient to be able to send back an encrypted message if a separate encryption certificate is being used. It was agreed that testing with different signing and encryption certs should be done to verify if it works for Microsoft. The HEPKI demonstration provides multiple certificates with different key usage bits so that can looked at as well and would allow verification of Netscape behavior.

Windows XP PKI Bridge Path Validation Testing: The goals are: to discover the best way to architect the CA to work with the bridge to support XP, what should go in the different Authority Information Access (AIA) fields at what levels and what changes are needed to the PKI-lite certificate profile so it's built into the profiles. There is a link to the testing document Jim put together at: http://pkidev.internet2.edu/bridge.

In the current test Higher Education bridge there's no control over the certificates and the CA's but there is the ability to issue the end entity certs. The question is: is it possible to make the bridge work in XP if you only have control of the end-entity cert? Yes, it can be made to work but it's not clear that's the optimal architecture. If you were building the whole bridge you would probably put in the AIA field just the information about the CA above it. When you get to the top level CA in your hierarchical CA that is the likely place to put the cross certificates. Or are there other actions that could be taken?

Tests were run using a signed document from Microsoft Word in Office XP. If there is only access to the end entity certs profile, all of the needed cross certs in the bridge can be put in a PKCS-7 blob. XP will follow the one AIA field link in the end entity cert, grab the PKCS-7 blob and build the trust path through the bridge. For an http URL everything works correctly. XP finds the pointer, discovers it does not have all the information to build the path, looks up the PKCS-7 in the URL, loads all the certs found into its cache, then correctly constructs and validates the path. Jim tested the equivalent LDAP setup, loading the cross certificates into an LDAP server and having an LDAP URL in the AIA field. Results were mixed. It didn't work every time when using signing in Office XP. It did seem to work in cases with control panel to verify the path and certificates.

Currently it's only clear that the identity cert works for sure. After discussion it was agreed that using the AIA for this purpose is rational and a logical starting point. Resolving issues with LDAP is a higher priority than testing AIA pointers and higher levels of the CA.

Eudora/ S/MIME document: The current version includes edits discussed previously but the explanatory text has not been written yet. Send feedback and suggestions to Jim.

The next call is Wednesday February 12, 2003.
Action Items

1. [AI] Eric will send a demo to the list when he gets further on this.
2. [AI] Jim will e-mail Dartmouth to see if they are doing private key protection for their CA.
3. [AI] Jim will see if Steve Hannah of SUN is available to participate in the next call.
4. [AI] Bob will forward Microsoft contacts from the OpenSSL list to Jim.