In message <[EMAIL PROTECTED]> on Sun, 19 Oct 2003 19:53:07 +0200, "Christian Barmala"
<[EMAIL PROTECTED]> said:
christian.barmala> Did I get it right:
I think I'll reorganise what you wrote to make it more readable (at
least for me):
Site 1
CA1 creates private key1 and CSR1
CA1 root certificate1a = CSR1 self-signed with private key1
Site 2
CA2 creates private key2 and CSR2
CA2 root certificate2a = CSR2 self-signed with CA2 private key
So far entirely correct. However, you're going right into a trap with
the following:
Site 1
CA1 root certificate1b = CSR1 signed with CA2 root certificate2a
Users CSRs are signed with CA1 root certificate 1b
Site 2
CA2 root certificate2b = CSR2 signed with CA1 root certificate1a
Users CSRs are signed with CA2 root certificate 2b
Note that in the entirely correct part, you wrote "signed with private
key", while here you're saying "signed with ... certificate". And
that's where confusion starts, first of all for yourself.
Repeat the following until you have it thouroughly ingrained into your
thinking:
A signature is made using a private key, not with a certificate
The only thing really coming from the CA certificate into the
certificate that's being signed is the subject, which becomes the
issuer in the cerificate that's being signed (oh, and some extensions,
but that's beside the point here).
So, a user CSR that's being signed is being signed with one of the two
keys key1 or key2, depending on which CA the user goes to. That means
that it can be verified with any of the certificates associated with
that key. So if the user CSR is signed with key1, it can be verified
with certificate1a as well as certificate1b.
As a diagram, the possible paths of validation can be shown like this
(and I really hope you read this with a monospace font, and that my
lack of ascii art experience won't bug you off too much :-)):
,--------. ,---------.
| | | |
| +----------+ +----------+ |
| | N: 1 | | N: 1 | |
| | I: CA1 | | I: CA2 | |
`--> | S: CA1 | | S: CA2 | <---'
| PK: key1 |. .| PK: key2 |
+----------+ `. .' +----------+
| `. .'
| `. .'
| `. .'
| `. .'
| .x
| .' `.
| |_ _|
| +----------+ +----------+
| | N: 2 | | N: 2 |
| | I: CA2 | | I: CA1 |
| | S: CA1 | <------> | S: CA2 |
| | PK: key1 | | PK: key2 |
| +----------+ +----------+
| /
| /
V |_
+----------+
| N: 3 |
| I: CA1 |
| S: user |
| PK: uk1 |
+----------+
Legends:
N: serial number.
I: issuer
S: subject
PK: public key (implies there's an association with the
corresponding private key)
The above shows a (very small) mesh of certificates with the two CAs
described above, and with a user that just got a certificate signed by
CA1. The arrows express verification. As you can see, there are two
ways to verify most certificates, and there are many possible paths to
verify the user certificate (I'm using square brackets to express the
tuple [issuer,serial number], which is basically the only way in this
example to identify one specific certificate instead of all
cerificates having a specific subject):
user <- [CA1,1]
user <- [CA2,2] <- [CA2,1]
user <- [CA2,2] <- [CA1,2] <- [CA1,1]
Which path is the one to use depends entirely on the trust point(s)
used by the application that wants to verify a certificate. A trust
point is basically a self-signed and self-issued certificate.
Note that the last one is a contorted way to end up with the same root
as the first example path.
Now, you've probably heard of certificate and key roll-over (which is
the process of changing the contents of a root certificate, or
starting with a new key). Basically, that's a special kind of cross
certification done within the same CA. Think about it, and if you
want me to talk about it, get back :-).
I'll say it again: OpenSSL doesn't handle a mesh like the above, and
neither does most browsers (Netscape, IE, Opera) as far as I know
(Opera uses OpenSSL, so I can probably make a very professional guess
:-)). It's being worked on (or at least planned).
--
Richard Levitte \ Tunnlandsv�gen 3 \ [EMAIL PROTECTED]
[EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
