The bridge CA architecture was designed to address the shortcomings of the trust list and cross-certified PKI architectures. The user cannot be expected to maintain current information on a large number of trust points. One the other hand, CA administrators need a mechanism for establishing trust relationships with other PKIs in a more efficient fashion.
The bridge CA meets these requirements, acting as sort of arbitrator. Unlike a mesh CA, the bridge CA does not issue certificate directly to users. Unlike a root CA in a hierarchy, the bridge CA does not issue certificates directly to users. All PKI users consider the bridge CA as an intermediary. The bridge CA establishes peer-to-peer relationships with different PKIs. These relationships can be combined to form a bridge of trust that connects the users from the different PKIs.
If the trust domain is implemented as a hierarchical PKI, the bridge CA will establish a relationship with the root CA. If the domain is implemented as a mesh PKI, the bridge CA will establish a relationship with only one of its CAs. In either case, the CA that enters into a trust relationship with the bridge CA is termed the principle CA.
In Figure 5-6, the bridge CA has established relationships with three PKIs. The first is Bob and Alice’s CA, the second is Carol’s hierarchical PKI, and the third is Doug’s mesh PKI. None of the users trusts the bridge CA directly. Alice and Bob trust the CA that issued their certificates, they trust the bridge CA because the Fox CA issued a certificate to it. Carol’s trust point is the root CA of her hierarchy; she trusts the bridge CA because the root CA issued a certificate to it. Doug trusts the CA in the mesh that issued his certificate; he trusts the bridge CA because there is a valid certification path from the CA that issued him a certificate to the bridge CA. Alice (or Bob) can use the chain of valid certificates, which includes certificates to and from the bridge CA, to establish relationships with Carol and Doug.
The trust relationship between the bridge CA and the principle CAs are all peer-to-peer. The trust relationships within the PKIs it connects are determined by their own architecture. Within the hierarchical PKI, trust relationships are superior-subordinate. Within the mesh PKI, the trust relationships are peer to peer.
It is easy to add new CAs, or entire PKIs, to a bridge-connected PKI. The change is transparent to the users, since no change in trust points is required. As the PKI grows, the number of trust relationships that must be established is far more manageable. In Figure 5-6, three trust relationships were established for three PKIs. This is the same as the cross-certified example shown in Figure 5-5. However, a bridge CA with PKIs will require 8 trust relationships, rather than the 28 required by the cross-certified example.
Turner c05.tex V3 - 03/26/2008 5:28pm Page 65
Chapter 5 ■ Understanding Public Key Infrastructure 65
Ops Legal R&D Doug Dove, Inc. HQ Legal R&D Carol Hawk Data Fox Alice Bob Fox Consulting Bridge CA
Figure 5-6 Connecting three PKIs with a bridge CA
The bridge CA does not resolve the certification path construction or validation problem. Path construction is just as complex as in a mesh PKI, since some of the PKIs are themselves a mesh. Certificates issued to and by the bridge may be very complex to ensure that the trust relationship is accurately conveyed. This increases the complexity of the path validation software.
In a bridge CA architecture, the PKI can easily recover from compromise. If the principle CA from a PKI is compromised, the bridge CA revokes its certificate. This invalidates the trust relationship between that PKI and any other PKIs. The rest of the relationships are not affected. If the bridge CA itself is compromised, it notifies the principle CAs. Since none of the users has the bridge CA as a trust point, the principle CAs simply revoke the certificates they issued to the bridge CA. For completeness, the bridge CA can issue a CRL revoking the certificates it has issued as well. The result is a set of separate PKIs, so users from different PKIs will lose the ability to establish secure services. On the other hand, it is straightforward to reestablish the PKI after rebuilding the bridge CA.
66 Part II ■ PKI Basics
X.509 Public Key Certificates
X.509 Certificates (see Figure 5-7) may be considered as three nested com- ponents. The first component is the tamper-evident envelope, provided by the
digital signature. Inside the envelope, we find the basic certificate content, which
includes the information that must be present in every certificate. The basic certificate content may include an optional set of certificate extensions. The vast majority of certificates generated today will include certificate extensions.
Tamper-Evident Envelope
At the outermost level, certificates have just three fields: the to-be-signed certificate, the signature algorithm identifier, and the signature value. Consider the tamper-evident envelope as a transparent plastic envelope around the certificate content. The message is easily read, but it cannot be modified without tearing the envelope. The fields are defined as follows:
tbsCertificate. This field contains the signed certificate, and its struc-
ture is discussed in the next section.
signatureAlgorithm. This field contains anAlgorithmIdentifierthat identifies an algorithm with an object identifier (OID) and optional
version serialNumber issuer validity subjectPublicKeyInfo extensions signatureAlgorithm signatureValue v3 48 080214120000Z to 080214120000Z RSA, 30 81 89 02 81 81 00 a7 ... 01 C = US; O = Hawk; CN = CA1
ECDSA with SHA-256
30 2c 02 58 ae 18 7c f2 16 ... 8d 48
signature ECDSA with SHA-256
subject C = US; O = Hawk; OU = R&D; CN = Alice
subjectUniqueID (Omitted)
issuerUniqueID (Omitted)
Certificate Contents
Tamper Evident Envelope
Options
Turner c05.tex V3 - 03/26/2008 5:28pm Page 67
Chapter 5 ■ Understanding Public Key Infrastructure 67
parameters. Here, only the algorithm identifier is included, and it iden- tifies the digital signature algorithm used by the CA to sign the certifi- cate. The optional parameters field is not used to validate the signature because this field is not inside the tamper-evident envelope. The informa- tion in this field is repeated in the signature field within the to-be-signed certificate, which is protected.
signatureValue. This field contains the digital signature. The digital
signature is computed using the ASN.1 DER encoded to-be-signed cer- tificate. The resulting signature value is encoded as a bit string, using conventions defined for the specified signature algorithm.