With reference to Charles' comments, I still have the> luxury of time before having to issue certs in anger.
With us it was not time, per se, if you notice the postings for our CA we had our first signing party in February of the year that our 5-year 1998 previous root expired in August. So that's 6 months of lead time.
Our problems were:
* Lack of a software inventory. In a corporate environment one might have a definitive list of the software in use, to be used as a checklist when planning the testing. In the case of (our?) University no such inventory exists. There is just no telling who might be using what where.
* Inability to mandate testing. There is just no way to persuade overworked and harried system maintenance personnel to "test our proposed upcoming system" before you actually go live and it's a matter of it breaking for the user or not. In a corporate environment one could (at least theoretically) get a mandate from management for mission critical systems to be formally tested. In our environment, with a weak king and strong barons, this is just not possible.
* Every application is a mission-critical application. If anybody (assistant professor or better? :-) screams it is a disaster, regardless of the true importance or unimportance of the application to the institution. You cannot count on IT management haveing any sense of proportion or reasonableness.
Whew...
References for my previous posting:
http://www.ietf.org/rfc/rfc3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
http://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-profile-current.html
http://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-root-profile-current.html
The root profile might be useful to you.
W/R/T the matrix
The vendor with the problem with DC/EMAIL (Novell) actually patched the problem before our August deadline, though I decided to redo the root before I was aware they were able to do this. I suppose you could make some statement about Netscape 4.7 not knowing about Extended Key Usage extension (anti-anti-missle-missle-missle? :-) and with some semantic knowledge of what the critical bit means* one could make some sense of things. I wonder about keeping it up to date, though -- might be a full-time job.
* Critical Bit:
if (verifyer-knows-about-this-extension) {
just do the right thing
else if (critical-bit-in-cert-is-set) {
FAIL VERIFICATION
else
verfyer is free to utterly ignore the extensionSo, in terms of extensions that will be newly created over the next ten years, they can just be ignored. What you are really worried about is:
A. Setting critical on an extension that some verifyer is
too old to know about (e.g., Netscape 4.7)B. Bug that causes software to crash in some situation.
There is no way to predict B or take B into account. This is why we must test mission critical applications.
-- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
