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]

Reply via email to