Well, since you didn't like my earlier bridge drawing,
there's a more orthodox one below. As for notation:
I tend to do a lot of diagrammatic reasoning myself,
so I tend to invent notation as I go along. If there
is a preferred notation [1] I'd be glad to redo these
diagrams in that form.
Since a certificate is essentially a public key signed
by a private key, I used the notation:
+---------------+
| (Private Key) |
+---------------+
| Public Key |
+---------------+
to denote a generic certificate. The signing private key is
in parentheses because it is not actually IN the certificate.
If the names in these diagrams are taken as the names of
public keys, then (X) means "signed with the private key
corresponding to the public key X". Note that in the vast
majority of cases the public key and private key will NOT
match each other. Instead, it will be the private key of a
superior CA signing the public key of either an inferior CA
or an end user.
A relying party may maintain a list of "trusted" certificates.
When a certificate is trusted the signer is irrelevant.
So sometimes I show a trusted certificate with a blank in
the signer:
+-+-------------+
|T| |
+-+-------------+
| Public Key |
+---------------+
and a flag [T] to show that "the buck stops here".
It is easy to follow the chain of trust with this notation:
+-+-------------+ +---------------+
|T| | | (Superior CA) |
+-+-------------+ +---------------+ ... until end user
| Superior CA | | Inferior CA |
+---------------+ +---------------+
I started representing a certificate as more than just an
atomic object while trying to understand networks like this:
+-+-----------+ +-------------+
|T| | | (B Root) |
+-+-----------+ +-------------+
| Server Sign | | Server Sign |
+------+------+ +------+------+
| |
+--------+--------+
|
v
+-------+-------+
| (Server Sign) |
+---------------+
| SSL End User |
+---------------+
in which more than one certificate can be said to have "signed"
an inferior certificate. In this case, it should be obvious
that both the trusted and untrusted certificates above should
have equal claim on having signed the lower certificate.
There is no "distinguished" signer [2].
Here is the updated bridge diagram. Note that there are a pair
of cross-certifying certificates for each member of the bridge
(this is what you were complaining about lack of, right?).
+-+---------+ +-+---------+
|T| | |T| |
+-+---------+ +-+---------+
| P Root +---------+ +---------+ Q Root |
+-----+-----+ | | +-----+-----+
| v v |
| +-----+-----+ +-----+-----+ |
| +->+ (P Root) | | (Q Root) +<-+ |
| | +-----------+ +-----------+ | |
| | | Bridge +--+--+ Bridge | | |
| | +-----------+ | +-----------+ | |
| | | | |
| | +--------+--------+ | |
| | v v | |
| | +-----+-----+ +-----+-----+ | |
| | | (Bridge) | | (Bridge) | | |
| | +-----------+ +-----------+ | |
| +--+ P Root | | Q Root +--+ |
| +-----+-----+ +-----+-----+ |
| | | |
| +-------+ +-------+ |
| | | |
v v v v
+--+-------+--+ +--+-------+--+
| (P Root) | | (Q Root) |
+-------------+ +-------------+
| P End User | | Q End User |
+-------------+ +-------------+
Unfortunately there are branched certificate chains here, so we
just have to hope that the various relying party software modules
get fixed up in time for us to actually DEPLOY something like this.
So, when a P relying party tries to verify a Q End User
certificate (we hope) it ends up with this certificate chain:
+-+-------------+
|T| |
+-+-------------+ Should be part of P's "Trusted Certificates"
| P Root |
+---------------+
+---------------+ Might be available from either the P LDAP
| (P Root) | directory or the bridge LDAP directory
+---------------+ Note: Q End User should NOT be expected to
| Bridge | supply this since it is not a member of
+---------------+ the P PKI
+---------------+ Might be available from either the Q LDAP
| (Bridge) | directory or the bridge LDAP directory
+---------------+ Note: if Q End User is expected to supply
| Q Root | this it would have to supply certificates for
+---------------+ ALL the bridges in which Q PKI participates
+---------------+
| (Q Root) |
+---------------+ Supplied by Q End User
| Q End User |
+---------------+
In this context, I'm trying to understand several paragraphs
from Chadwick's 2003 paper [3] which talk about using the
Authority Information Access and Subject Information Access
extensions to develop the required certificate chain:
From page 7 of the PDF version:
PKIX Certificate Extensions.
Because LDAP directories were typically standalone directory
islands that did not have knowledge of each other, the IETF
PKIX group specified several certificate extensions designed
to allow PKI clients to find the correct LDAP directory for
their needs. This was effectively building LDAP knowledge
references into certificates. First, they specified the
precise contents of the X.509 CRL Distribution Points extension.
This extension informs the client where CRLs may be found,
and when CRLs are located in an LDAP directory, PKIX mandates
that the distribution point name must be a LDAP Uniform Resource
Identifier (URI), for example,
ldap://directory.ja.net/cn=distribution point, c=gb.
Secondly, for hierarchical PKIs, subordinate CAs may include in
their issued certificates a list of their superior CAs up to the
trusted root of the hierarchy, along with the LDAP URIs of their
directory services, for example,
ldap://superior.directory.com/o=superiorCA, dc=myorg, dc=com.
This information is held in a newly defined Authority Information
Access extension.
Finally, for cross-certified CAs, the cross certificate may hold
the location of the certified CA's LDAP directory in a newly
defined Subject Information Access extension for example,
ldap://ldap.otherCA.com/o=crossCA, dc=orgname, dc=com.
So I'm trying to find a set of extension definitions for the
certificate chain above such that the (P Root)Bridge and
the (Bridge)Q Root certificates can be discovered, I guess
somehow starting with an AIA in the Q End User certificate?
Although I think "bridge" is a case of "cross-certified CAs"
so I would expect SIA to be in the mix somewhere???
Thanks for considering this.
[1] I did see one notation on the web where somebody was using
strings like <<signer>>signed or something like that.
I suspect I could represent these diagrams as something like:
(Signer)Signed or [T]Signed but this might conflict with the
more or less standard notation for symmetric encryption. TBD.
[2] This is because the "Authority Key Identifier" is a hash of
the subjectPublicKey which could appear in a number of diverse
certificates from different authorities (I guess this is
technically incorrect when the alternative AKI form of
issuer name and serial number is used).
[3] "Deficiencies in LDAP when used to support PKI",
Chadwick, David (University of Salford UK),
CACM V46#3 (March 2003)
http://portal.acm.org/citation.cfm?id=636772.636778
http://sec.isi.salford.ac.uk/download/CACMPKILDAP.pdf
--
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]
