July 30, 2003
Attendees

* Jim Jokl, U. Virginia
* Eric Norman, U. Wisconsin
* Mark Franklin, Dartmouth
* Barry Ribbeck, UT-HSCH
* Nathan Faut, Educause
* Steve Worona, Educause
* David Wasley, UCOP
* Scott Cantor, OSU
* Neal McBurnett, Internet2
* Bob Morgan, U. Washington
* Renee Frost, Internet2
* Jeanette Fielden, Internet2

Discussion

The USHER CA key will have a five-year life. The validity period will be at least ten years but may be as long as twelve years. A series number will be used in the common name to identify each version of the CA.

Nathan confirmed that there are two OID's for the C4, one for temporary issuance and one is for cross certification. So there does appear to be a level that is designed to be permanent.

Barry talked with an auditor at UT-HSCH, who is a CPA/CISSP, about CPS/CP audits in term of CA's. Her opinion was that credentialing is not as critical as the auditor's background/experience. If it's a documented audit, any auditor can go through that document and do typical audit things to verify. If technical understanding is required then you need someone with a technical/IT/auditor background. So the CPS should be as detailed as possible. She was not aware of any standard audit best practices for evaluating CA's. It was generally agreed that a document of general principles and references for auditing would be helpful but the help of a couple of auditors would be extremely helpful.
[AI] Barry will bring the idea up at the next UT system security team meeting for suggestions and ideas.
[AI] Jim, Renee, and anyone else with system auditors will contact them to see if there are auditors interested in participating in creating such a reference document.

Bob inquired at the IETF meeting if having a FIPS crypto module would be sufficient to meet the requirement and was not able to get a definitive answer if it was or not.

The idea of using the same CA and different OID's to represent levels of assurance was discussed. The usher CA could use different OID's depending on what the campus is trying to do, i.e. fed medium vs. PKI-lite. There was concern that it would be another barrier to implementation, and there was uncertainty over whether it affected the cost of services. There also appears to be no one currently requesting such functionality. The general consensus was that the flexibility to verify and support multiple OID's should be retained but there are no drivers for implementation at this time.

Bob Morgan raised a general issue about certificate discovery and acquisition that is especially relevant for bridge-based PKIs. If you are trying to evaluate a certificate and need to acquire other certificates to do path validation how do you do that? It is not in general clear what CAs a given relying party trusts so the normal method of sending a "full chain" to the relying party doesn't work. Approaches to deal with this include 1) pushing the problem to an OCSP server, which is easier to keep well configured, and 2) Microsoft's use of AIA fields to track down what is needed.

This is an opportunity to encourage Microsoft to write down exactly what their software does since the details are now known. There was general agreement that the path validation document could be updated to make recommendations on how to do this.

Kiosk environments and hardware tokens: A new version of the Rainbow iKey software has a cert auto-registration deletion feature that works with Microsoft only. When you plug the iKey in it registers the certificate and you can configure it to automatically remove it when the device is removed so you don't end up with all these certs floating around. UT-HSCH is using it and it works very well.

U. Virginia has had some discussions with Apple about their future plans with respect to native key stores and Internet Explorer issues.
[AI] Jim will try to get an Apple representative to join us for a call and go over their future plans.

Mark sent out an e-mail regarding windows certificate store issues and enforcing passwords. He wants to enforce the strong password protection so that every time they use the key they have to type the password. Consensus was there is no way to enforce that other than hardware. Some institutions are using multi-factor authentication to ensure that for certain applications that the person is still at the computer and who they say they are through a shared secret or similar measure. There is no universally agreed best approach to solve the issue.

Next call is Wednesday, August 13, 2003