September 10, 2003
Attendees

* Jim Jokl, U. Virginia
* Eric Norman, U. Wisconsin
* Steve Worona, Educause
* Shelley Henderson, USC
* Eric D?, Columbia
* Jeff Schiller, MIT
* Mark Franklin, Dartmouth
* Steve Carmody, Brown
* Jeanette Fielden, Internet2
* Renee Frost, Internet2
* Neal McBurnett, Internet2
* Steve Olshansky, Internet2
* Ken Klingenstein, Internet2

Discussion

The Usher CP discussion focuses on the differences between PKI lite and a heavy weight policy. Is USHER is going to put requirements on the campuses or just let the campuses follow the lite model? The CP and practices are about how USHER itself is operated.

Steve delineated what he sees as two use cases. The first is InCommon and simplifying the process of managing the trust fabric. It's a single CA and doesn't have to have anything to do with broader issues in Higher Ed. The second case relates to S/MIME. Although there are not many S/MIME deployments, schools are thinking about it and the implications of inter-campus S/MIME. They are interested in making it easier to manage the trust fabric.

For the federal bridge there a lot of very heavy requirements. Do you impose requirements on everyone in order to serve the two or three people that need access to the federal bridge? Or do most campuses just want a CA to enable interaction with other campuses to enable research collaboration. For grant proposals with the federal government it should be possible to build on top of the PKI infrastructure.

There needs to be some level of confidence that schools can have in the USHER CA and what physical level of security it's run at. The USHER CA needs to be run securely at a level beyond PKI-lite. There needs to be a clear explanation of how you're protecting the private key and tying into the I&A process on the subordinate CAs. The initial level will likely not translate into a federal level of assurance at medium or basic since there are expensive auditing and physical security requirements, which may discourage institutions from participating.

The first USHER CA will follow a CP from the FBCA "Citizen and Commerce" school which is similar to "HEPKI-Lite". It would be a short CP without extensive restrictions on the CPs of the subordinate CAs and detailed legal and technological prescriptions. It will enable institutions to build on the capabilities of InCommon and Shibboleth and establish new sorts of federated trust. Higher Ed will be able to deploy S/MIME and similar inter-institutional technologies and move away from password-based and IP-number-based authorization.

As demand and expertise increases additional CAs will be added that correspond to progressively higher levels of assurance such as the Federal "Basic" or "Medium" LoA using the full HEBCA-compliant HECP.

Eric indicated that it needs to be discussed how the public keys and certificates will be deployed and verified. Jeff is still working on hardware issues to find a device that supports 2048 bit key loading. He's also considering how a safe might be used to run an on-line server in lieu of a secure room. The current focus is getting the Rainbow token to run in house under Linux.

There will need to be documentation that follows a standard format that incorporates a CP, a CPS and standard practices so people can understand what is being offered. It is not clear if it will be a kind of a formal policy and practices that fits a model, or more simply documenting what everyone thinks is a good technical solution and the I&A process as policy practices.

Neal has been trying to find time to look at the PKI challenge which came up with a number of specific interoperability issues and if they've been considered or not.
Jim indicated he could help with that.
[AI] A formal last call on Jim's profile posted on the HEPKI page will be sent out.

Jim has received some responses to his e-mail about S/MIME. If anyone knows of smaller limited S/MIME projects they would be welcome as well. He would like to see an updating of the S/MIME client table to include Pine, Mulberry and any other e-mail clients. Updating can be handled via the e-mail list.
[AI] All. Please let Jim know of any other schools doing S/MIME that are not currently listed.

Jim will co-ordinate some of the audit components for the training documents for Campus CA's and Internal Audit.

Neal asked if anyone has a better description of Open SSL and FIPS 140 certification than is in the press. What's unclear is how many applications that people actually use are actually running in FIPS mode. What is different when an application is running in FIPS mode?
[AI] If anyone has a product running in FIPS mode please let Neal know.

There has been some work done at Dartmouth putting patches in the LINUX kernel to turn it into a poor mans secure co-processor which might be of help with the FIPS certification. The Slashdot entry about Dartmouth's Linux "Open-Source Virtual Secure Coprocessor based on TCPA" is available at:
http://developers.slashdot.org/developers/03/09/10/0255245.shtml?tid=106&tid=126&tid=172&tid=185. It has a link to the Dartmouth paper and to several by IBM.

Shelley gave an overview of USC and how they've responded to the announcement that Globus is shutdown their CA. They've created an institutional CA with a CP based on PKI Lite meant to have a lifespan of about six months to allow them to gain experience. The CA uses OpenSSL, and is set up so that only two people on staff can actually issue certificates. Emergency access is allowed if neither of those two people is available, but it requires two other staff members to unlock. The CA machine is not in a vault but is non-staff inaccessible and connected to the campus network. Initially, the USC CA will issue certificates only for hosts and persistent processes/services, not for users. User PKI certs are created using kx.509 with authentication based on Kerberos.