In message <[EMAIL PROTECTED]> on Thu, 23 Sep 2004 17:49:09 +0400, Toxa <[EMAIL
PROTECTED]> said:
postfix> On Thu, Sep 23, 2004 at 02:47:20PM +0200, Richard Levitte - VMS Whacker wrote:
postfix>
postfix> > That is an entirely different question. You can place all
postfix> > relevant certificates in a PKCS#12 file, or just
postfix> > concatenate them in one .PEM file.
postfix>
postfix> Would you mind to clear it out for me... It any CA has been
postfix> cross-certified with another one, all users of that CA have
postfix> to import their CA's cross-certificate in order to trust
postfix> users of another CA, but they still has to keep old CA cert,
postfix> right?
Yes, although the term "old" is a mismoner. Here's the extended
explanation:
Any user or process really only needs the root certificate for their
own point of trust (their CA), and all intermediate certificates to be
able to certify all certificates they stumble upon when communicating
with other.
So, if we take a really easy example, with two CAs, CA1 and CA2. CA1
has a self-signed certificate CA1c1 (the notation will become apparent
in a moment) and CA2 has a self-signed certificate CA2c1. CA1 has a
few users, called CA1U1, CA1U2 and so on, each having one certificate
each, called CA1U1c1, CA1U2c1, and so on. For CA2, my imagined names
are CA2U1, CA2U2 and so on, having a certificate each called CA2U1c1,
CA2U2c1 and so on. A way to display the certificate structure could
be:
+---+ +---+
| V V |
| +-------+ +-------+ |
+-| CA1c1 | | CA2c1 |-+
+-------+ +-------+
| |
+-> CA1U1c1 CA2U1c1 <-+
+-> CA1U2c1 CA2U2c1 <-+
: :
In this picture, all the users CA1U{x} have CA1c1 as certificate for
their point of trut. Similarly, the users CA2U{x} have CA2c1 as
certificate for their point of trust.
After cross certification, each CA has signed a *new* certificate for
the other CA, meaning CA1 has signed a certificate for CA2 and vice
versa. Note that these new certificates do NOT REPLACE their old
certificates. This means that you get a picture like this:
+---+ +--------------------------+ +---+
| V | V V |
| +-------+ +-------+ +-------+ +-------+ |
+-| CA1c1 | | CA1c2 |<--+ | CA2c2 | | CA2c1 |-+
+-------+ +-------+ | +-------+ +-------+
| | | | | |
| | +--------------------+ |
| | | |
+-> CA1U1c1 <-+ +-> CA2U1c1 <-+
+-> CA1U2c1 <-+ +-> CA2U2c1 <-+
: :
As you can see, the certificates CA1c1 and CA1c2 can both be used to
verify the certificates CA1U{x}c1, since they both contain the same
public. The same goes for the corresponding certificates in the realm
of CA2.
Now, for users and processes CA1U{x} to verify certificates for the
users and processes CA2U{y}, they need to be able to verify back to
their own CA. If you look, the only path is CA2U{x}c1 <- CA2c2 <- CA1c1.
Similar paths can be built the other way. What the users need to do
for this to happen is to somehow have access to the cross certificate
from the *other* CA, nothing more. They keep the root certificate for
their own CA. This means that all the users CA1U{x} need to have
access to CA1c1 and CA2c2, and that all users CA2U{x} need to have
access to CA2c1 and CA1c2.
I say "have access to" because certificates can ideally be found in
all sorts of mediums, for example LDAP repositories (in an ideal
world, it would mean that the users would need to do absolutely
nothing). In a classic browser situation, the users CA1U{x} would
therefore really only need to download the newly created CA2c2, and
the users CA2U{y} would need to download the newly created CA1c2.
nothing more, since I assume they already have the root certificates
for their own CA, but for good measure (and for new users), it would
be smart to pack the needed root certificate in the same PKCS#12 as
the other CA's cross certificate.
postfix> What if user import new cross-certificate only, without
postfix> installing old CA cert?
Then things won't work, and the CA admin has made an ass of him- or
herself.
postfix> I suppose it depends on functionality of cross-certificate...
postfix> And the last one, imagine two cross-certified CAs which were,
postfix> for example, self-signed, suddenly resign their root certs in
postfix> order to be subordianted by new Root CA (e.g. their new
postfix> certificates signed by those root CA). What about new
postfix> certificate chain for users of those CAs, will it be based on
postfix> cross ceritifcate, of based on new root CA.
If a CA resigns it's root certificate, it means that it has become
completely subordinate to the other CA instead of just being a
partner. That's fine, just have the users throw away that root
certificate. If CA1 in the example above would do that, the hierarchy
would then become this:
+---+
V |
+-------+ |
| CA2c1 |-+
+-------+
| |
V +-> CA2U1c1
+-------+ +-> CA2U2c1
| CA1c2 | :
+-------+
|
+-> CA1U1c1
+-> CA1U2c1
:
Did you notice how CA2c2 disappeared? That's because CA1c1 was thrown
away, making CA2c2 unverifiable and therefore completely unnecessary.
In this case, the users CA1U{x} have to get access to CA1c2, and for
software who can't handle several certificates with the same subject
(such as OpenSSL, for now, *groan*), it means they have to thrown away
CA1c1 first. The users CA2U{y} don't need to do anything.
postfix> CA1 and CA2 are cross-certified, both subordinated by
postfix> CA0. For user of CA1, picking certificate of user of CA2,
postfix> the chain will be:
postfix>
postfix> [CA1] -- [CA2]
postfix>
postfix> or
postfix>
postfix> [CA1] -- [CA0] -- [CA2]
The former, unless it's a full mesh (i.e. CA1 and CA2 both also are
fully cross certified with CA0), but in that case, you have both
choices, and smart software would pick the shortest path.
Was that enough information for you, and did it answer your question
to your satisfaction? I can talk about this all week :-).
And remember, there's really nothing magic about cross-certification,
it's basically just one more certificate for each involved CA, to be
use *in parallell* with their other certificates.
Cheers,
Richard
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/
"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
