April 23, 2003
Attendees

* Jeff Schiller, MIT
* Jim Jokl, Virginia
* Scott Cantor, OSU
* Michael Gettes, Duke
* Gary Chapman, NYU
* Renee Frost, Internet2
* Eric Norman, Wisconsin
* Bob Brentrup, Dartmouth
* Bob Morgan, Washington
* Neal McBurnett, Internet2
* Jeanette Fielden, Internet2
* Ken Klingenstein, Internet2

Discussion

There are 121 registered participants for the PKI workshop next week.

Jeff has talked to BBN and they will support the Safekeeper. The battery is not measured in absolute life but in absolute voltage, so if it's left on it will last longer. Fortunately, the machine has been left on pretty much continuously although it's not clear if there's any command available to check the voltage.

CREN CA Migration: The discussion centered on what do we want for an institutional INA process?

The user name and password can be communicated to the technical contact out-of-band.
There will be three roles, the administrative contact, the technical contact, and the institution signing authority. While there may be some overlap between roles a person can hold no more than two of the three roles, i.e. there must be at least two different people listed for the three contacts. Renewals, etc. would not have to go through the high-level administration contact, but through the technical contact. The key is the university has to decide who their administrative and technical contacts are. The technical contact should be someone who's familiar/involved with the certificate and its uses.

The overall process remains essentially the same, the difference is, instead of PGP signed exchanges an SSL protected web form will be used. This would also provide the advantage of all entered information being automatically put in a database. There will be an out of band mechanism to get the login and password back to the technical contact. It was decided to retain a physical application with signatures that can be faxed. This is to ensure that a given institutions process regarding who has signing authority for it can be followed. On the actual form signed by the university, the person who signs can certify the admin and technical contacts. They'll still be validated, all three, through the university switchboard.

Certs: One model is to say Internet2 is not issuing server certs, just enterprise certs. The institute themselves must provide the server certs. So the model is both an InCommon CA run at Internet2 and the possibility for campuses to not use that and do their own.

One could let campuses obtain a CA certificate signed by the top-level CA and then turn around and issue certs they can use in Shib. If a relying party can somehow say I am willing to trust the CREN root but only at zero path length i.e. I'm not willing to trust an indirectly issued cert. Another way to do it is by using name constraints. It would need to be against any policy for a campus to issue something that claims to be a Shibboleth credential for another campus.

How strongly do we feel about enforcing things? If we feel that that name constraints are a requirement we should probably go back to just having the CREN CA issue the Shib certs. Shib/InCommon can get started with that and it can be extended later to campus issued certs for that purpose. So for version one the result will be getting the campus certificate signed and Shibboleth certificates.

Revocation Policy and Practices: In the current CREN profile there are no CRL pointers. Is that something to change as part of the new process, generate CRL's? The problem with CRL's is that there is no standard place to get them, software that universally uses them etc. If a key was compromised we could issue a CRL. We'd probably send mail to all the contacts at schools stating that we issued a CRL that invalidates the certificate.

After discussion it was agreed to investigate completely revising the CREN CA server and consider hardware changes, naming, cert profile, key storage, everything. There is never an optimal time to do this but if it's implemented properly then the inconveniences are worthwhile. This also offers the opportunity to reduce reliance on an outside vendor.

Jeff will document procedures for generating, storing and safeguarding a key.
Things to be incorporated include witnesses, key storage on cd's, tamperproof measures, how to reconstitute the key etc. If we decide to generate the key and store it we can do something by July.

Neal will bring the list of open issues to the PKI workshop for a BoF discussion.

The discussion on other aspects, such as assurance levels will continue on the next call. May 7th 2003.