The trust list is the most straightforward way to handle more than a single CA, as described previously. In this architecture, more than one CA provides PKI services, but there are no trust relationships between CAs. In this model, Alice maintains a list of CAs that she trusts. She trusts valid certificates issued by any of them. New CAs can be added to the PKI by modifying the trust list. As with a single CA, there are no trust relationships. The users accept only certificates and CRLs issued by CAs in their trust list. As a result, one certificate and one CRL are all that is needed for any user. However, this is complicated slightly by the increase in the number of trust points. There are no CA certificates, so complex certificate extensions do not appear. Certificate path construction and analysis are very easy.
In Figure 5-2, Carol has obtained certificates for Hawk Data Company CA. There is no trust relationship between the Fox CA and the Hawk CA. Alice wants to communicate with Carol securely, but there is no certificate path beginning with Fox CA (whom Alice trusts most) that ends with Carol’s certificate. Alice needs to add a new CA to her trust list. Once Hawk CA is added to her trust list, Alice can verify Carol’s certificate.
The primary advantage of this architecture is simplicity, because there are no certification paths, just single certificates. In addition, the mechanism of adding a new CA to the PKI is very straightforward; Alice simply adds one more CA to her list of trusted CAs.
Turner c05.tex V3 - 03/26/2008 5:28pm Page 59
Chapter 5 ■ Understanding Public Key Infrastructure 59
Alice's Trust List Fox X Y CA X User Y X Y CA X issued a certificate to User Y. Legend Bob Alice Hawk ... Fox Hawk Doug Carol
Figure 5-2 Supporting multiple CAs through a trust list
There are important disadvantages, however. Alice added the new CA to her trust list out of expediency because she wanted to communicate with Carol. However, Alice really should have investigated the Hawk CA before she added it to her trust list. In addition, Alice should maintain critical information about every CA that she trusts. As this number grows, it will be very difficult for her to keep this information up to date.
CA compromise is very difficult to handle with trust lists. If the Hawk CA private key is compromised, then it will probably notify all its users immedi- ately. However, the Hawk CA does not have a direct relationship with Alice; the Hawk CA probably does not even know that it is a member of Alice’s trust list. Alice will continue to trust certificates issued by the compromised CA.
Hierarchical PKI
The traditional PKI architecture is hierarchical PKI. In this architecture, multiple CAs provide PKI services, and the CAs are related through superior- subordinate relationships. In this architecture, all users trust the same central
root CA. With the exception of the root CA, all the CAs have a single superior
CA. CAs may have subordinate CAs, issue certificates to users, or both. Each CA trust relationship is represented by a single certificate. The issuer is the superior CA, the subject is the subordinate.
To add a new CA to the PKI, one of the existing CAs issues a certificate to the new CA. The new CA is grafted directly under the CA of the existing PKI, and the new CA becomes the subordinate of the issuing CA. Two hierarchical PKIs may be merged in the same fashion.
Certification paths are easy to develop in a hierarchy because every CA has a single superior CA. There is a simple, obvious, and deterministic path from a user’s certificate back to the single trust point at the root. The certification paths are relatively short. The longest path is equal to the depth of the tree: a CA certificate for each subordinate CA, plus the user’s certificate. Superior CAs may impose restrictions upon the subordinate’s actions. These restrictions
60 Part II ■ PKI Basics
could be maintained through procedural mechanisms or imposed through the certificates themselves. In the last case, the CA certificate will contain additional information to describe these restrictions. (The types of restrictions are discussed later in this chapter.)
In Figure 5-3, the R&D, Legal, and Ops CAs have joined a small hierarchical PKI. The root CA is the HQ CA. Alice sets her trust point to HQ, even though she obtained her certificate from the R&D CA. Alice can easily construct Carol’s certification path, which contains a single certificate. The path contains more certificates, and the CA certificates contain additional information that must be processed.
Hierarchical PKIs handle the compromise of a single CA within the infras- tructure easily, as long as it is not the root CA. If a CA is compromised, its superior CA simply revokes its certificate. The superior issues a new certifi- cate to the CA, containing the new public key and bringing it back into the hierarchy. Once the CA has been reestablished, it issues new certificates to all of its users. In the interim, transactions between any two users outside the compromised part of the PKI can proceed. Of course, users in the compromised part of the hierarchy lose all services.
On the other hand, the compromise of a root CA has as catastrophic an impact as in the single CA architecture. It is critical to inform all the users in the hierarchical PKI that the root CA has been compromised. Until the root CA is reestablished, issues new certificates to its subordinates, and distributes the new trust point information, users cannot use the PKI to establish secure communications. There is one advantage in comparison to a PKI consisting of a single CA: The root CA will have to reissue a much smaller number of certificates. In addition, the root CA can operate offline, significantly reducing the likelihood of key compromise.
X Z CAX User Z Y Z CA X issued a certificate to User Y. Legend HQ Bob Alice
R&D R&D Ops Carol Bob X CA X is superior to CA Y. Y
Turner c05.tex V3 - 03/26/2008 5:28pm Page 61
Chapter 5 ■ Understanding Public Key Infrastructure 61
Mesh PKI
The mesh PKI architecture is the primary alternative to a hierarchy. This archi- tecture is also referred to as the network PKI or a web of trust. In this architecture, multiple CAs provide PKI services, and the CAs are related through peer-to-peer relationships. Each user trusts a single CA; however, the trust point is not the same for all users.
In general, users will trust the CA that issued their certificate. CAs issue certificates to each other; a pair of certificate describes their bidirectional trust relationship.
A new CA can easily be added to a mesh PKI. The new CA issues a certificate to at least one CA that is already a member of the mesh, and it issues a certificate to the new CA. However, path construction is particularly difficult in a mesh PKI. In a hierarchy, building a certification path from a user’s certificate to a point of trust is deterministic. In a mesh, this process is nondeterministic. Path discovery is more difficult since there are often multiple choices. Some of the choices lead to a valid path, but others result in useless dead ends. Even worse, it is possible in a mesh PKI to construct an endless loop of certificates. The length of a path may be longer than in a typical hierarchical PKI. In the worst case, the path length can approach the number of CAs in the PKI.
Certificates issued in a mesh PKI are also more complex. Since the CAs have peer-to-peer relationships, they cannot impose conditions governing the types of certificates other CAs can issue. If a CA wishes to limit the trust, it must specify these limitations as certificate extensions in the certificates it issues to all of its peers.
Mesh PKIs are very resilient since there are multiple trust points. Com- promise 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 communicate 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 simpler in a mesh CA than in a hierarchy PKI, primarily because it affects fewer users.
In Figure 5-4, the CAs are incorporated into a mesh PKI. Alice and Bob trust the R&D CA, Carol trusts the Legal CA, and Doug trusts the Ops CA. It is more difficult for Alice to find and analyze a certification path for Carl than in a hierarchical PKI. The certification path may contain two or three certificates. It contains two if the path from the R&D CA directly to the Legal CA is used. However, it contains three certificates if the path through the Ops CA to the Legal CA is used. While attempting to find one of these valid paths, Alice may also follow other paths that result in dead-ends. For example, Alice might try a path that includes the HQ CA. The certificates will also be more complicated to
62 Part II ■ PKI Basics
process, since all limitations in trust relationships are expressed as additional information in the certificate.