P1: JDW
PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0
PUBLICKEYCERTIFICATES 159relationship. The same constraint mechanisms that were
used in the hierarchical PKI may be used to avoid placing
unrestrained trust in other CAs.
A new CA can easily be added. The new CA issues a
certificate to at least one CA that is already a member
of the mesh, who also issues a certificate to the new CA.
Path construction is particularly difficult in a mesh PKI;
however, it is nondeterministic. Path discovery is more
difficult because there are often multiple choices. Some
of these choices lead to a valid path, but others result in a
useless dead end that does not terminate at a trust anchor.
Even worse, it is possible to construct an endless loop of
certificates.
Certificates issued to CAs in a mesh PKI are also more
complex than the ones usually found in a hierarchical PKI.
Because the CAs have peer-to-peer relationships, the cer-
tificates contain constraints to control certification paths
that will be considered valid. If a CA wishes to limit the
trust, it must specify these constraints as certificate exten-
sions in the certificates issued to all of its peers.
Because Mesh PKIs include multiple trust points, they
are very resilient. Compromise of a single CA cannot bring
down the entire PKI. CAs that issued certificates to the
compromised CA simply revoke them, thereby removing
the compromised CA from the PKI. Users associated with
other CAs will still have a valid trust point and can com-
municate securely with the remaining users in their PKI.
In the best case, the PKI shrinks by a single CA and its
associated user community. At worst, the PKI fragments
into several smaller PKIs. Recovery from a compromise
is simple and straightforward, primarily because it affects
fewer users.Hybrid PKI Architectures
Two approaches are commonly used to join two or
more enterprise PKIs: cross-certification and a bridge CA.Figure 4: Certification paths with cross certified PKIs.Figure 5: Certification paths with a bridge CA.Both techniques establish peer-to-peer trust relationships.
Figure 4 shows one example of a cross-certified PKI.
This architecture is an appropriate solution to estab-
lish trust relationships between a few enterprise PKIs. In
Figure 4, three peer-to-peer relationships and six CA cer-
tificates were required to establish these relationships.
This number grows rapidly, however, as the number of en-
terprise PKIs increases. Cross-certifyingnenterprise PKIs
requires (n^2 −n)/2 peer-to-peer relationships and (n^2 −n)
certificates. Establishing these relationships requires a
time-consuming review of policies and practices.
Figure 5 shows the same enterprise PKIs establishing
trust via a bridge CA. Unlike a mesh CA, the bridge CA
does not issue end-entity certificates. Unlike a root CA in
a hierarchy, the bridge CA is not intended for use as a
trust point. All PKI users consider the bridge CA as an
intermediary. The trust relationships between the bridge
CA and the principal CAs are all peer-to-peer. It is easy
to add new CAs, or entire enterprise PKIs, to a bridge-
connected PKI. The change is transparent to the users,
because no change in trust points is required. In general,
the use of the Bridge CA will require less time to be spent
reviewing policies and practices than a comparable Cross-
Certified PKI.
Neither cross-certification nor the bridge CA simplified
certification path construction or validation. In general,
path construction is just as complex as in a mesh PKI;
however, path construction can be greatly simplified if CAs
are aligned with the name space in which the certificates
are issued.PUBLIC KEY CERTIFICATES
The X.509 public key certificate is named after the
document in which it was originally specified:CCITT
Recommendation X.509.This document, first published