Follow up to previous posting: I did try to do some experimentation in the context of trying to design a clean transition from the root we made in 1998 to the root I made in 2003. I did not have a great deal of success because the browsers I was working with at the time (Netscape 4.7x and IE 4 or 5) could not properly deal with what the PKI theoreticians call a "branched certificate chain", which was what was really needed to address that problem.
Could the PKI theoreticians acknowledge the fact that the real world certificate verifiers out there in fact cannot properly deal with a branched certificate chain, and that this deficiency severely limits the utility (e.g., truth :-) of statements such as
"If the enterprise merges or joins a commercial PKI (such as Identrus), then we only need to get the root certificate signed by our new "super root"?
Needed added text:
AND arrange for the NEW CERTIFICATE formed by getting our root certificate signed by our new "super root" to be available to the certificate chain validation software out there in the clients,
AND make sure that in none of the four transition cases* is there any ambiguity in forming the certificate chain to be verified (this is the "branch" question) since the browsers don't deal well with trying to deal with branched certificate chains?
Or am I living in the past, and up-to-date browsers have been fixed so this is no longer a problem???
N.B., the branched-certificate-chain case also occurs when you talk about so-called "bridged PKIs".
You have been warned. ====================
*Four transition cases I was considering:
1. unmodified client and unmodified server 2. unmodified clinet and "updated" server 3. "updated" client and as-yet unmodified server 4. updated client and server
In all fairness my case was a bit harder since it was from one local root to another local root so it could not be assumed that the new local root was already in the client, while the present situation is that we can assume that the "Identrus" root is already present in the client, so the case of an unmodified client does not happen...
-- 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]