Cryptography Reference
In-Depth Information
3. CA1 has vouched for the information in Alice's public-key certificate (because
CA1 generated and signed it);
4. Therefore, I (Bob) trust the information in Alice's public-key certificate.
CERTIFICATION HIERARCHIES
The second technique, which we also encountered in Section 11.2.2, is to use
a
certification hierarchy
consisting of different levels of CA. A higher-level CA,
which both CA1 and CA2 trust, can then be used to 'transfer' trust from one
CA domain to the other. The simple certification hierarchy in Figure 11.6 uses a
higher-level CA (termed the
root CA
) to issue public-key certificates for both CA1
and CA2. Relying party Bob of CA2, who wishes to trust a public-key certificate
issued to Alice by CA1, can do so by means of the following argument:
1. I (Bob) trust CA2 (because I have a business relationship with CA2);
2. CA2 trusts root CA (because CA2 has a business relationship with root CA);
3. Root CA has vouched for the information in CA1's public-key certificate
(because root CA generated and signed it);
4. CA1 has vouched for the information in Alice's public-key certificate (because
CA1 generated and signed it).
5. Therefore, I (Bob) trust the information in Alice's public-key certificate.
CERTIFICATE CHAINS
The joining of CA domains makes verification of public certificates a potentially
complex process. In particular, it results in the creation of
certificate chains
, which
consist of a series of public-key certificates that must all be verified in order to
have trust in the end public-key certificate. Just as an example to illustrate this
complexity, consider the apparently simple CA topology in Figure 11.7. In this
Root CA
Certification
CA1
CA2
Clients of CA1
Clients of CA2
Figure 11.6.
Certification hierarchy
