Cryptography Reference
In-Depth Information
single CA would clearly entail a great risk because if it does not perform its activity
correctly—be it because of corruption, inefficiency or any other reason—then its
failure would mean the failure of the entire system.
What happens in practice is that there are multiple CAs and this means that it
is virtually impossible for a user to have access to the public keys of all of them.
However, a user A may choose from CAs which issue a certificate and may have
certificates from different CAs issued to her for the same public key. Then A can
offer these certificates to other users who can choose the CA they trust among all
those that emitted certificates to A . For example, it is common that web browsers
come with a number of CA public keys pre-loaded in their certificate store, enabling
the user to select those she is willing to trust.
There is, however, a problem inherent to the use of multiple CAs and this is
the fact that two different users may trust different CAs but nevertheless want to
communicate securely with each other. Suppose, for example, that A trusts CA 1 and
has CA 1 's public key pk CA 1 as well as a certificate for her public key issued by CA 1 .
Similarly, B has a certificate issued by CA 2 as well as CA 2 public key. A might
send to B her certificate to allow B to make use of her public key but B cannot, in
principle, authenticate this key because he does not have pk CA 1 . However, suppose
that B obtains a certificate issued by CA 2 containing pk CA 1 . Then B is assured that
A 's key is authentic by making two verifications. First B verifies CA 1 's public key
with CA 2 's public key and then he verifies A 's public key with CA 1 's public key.
This way, a certificate chain (called a chain of trust ) is established. Note that in this
chain, a delegation of trust is produced when B not only verifies CA 1 's public key
but also trusts CA 1 as an issuer of certificates.
Situations like the one just described lead to the approach of making CAs certify
each other. However, it might happen that not all CAs certify each other and so,
in practice, CAs are often arranged hierarchically, so that CAs issue certificates to
lower-level CAs. In a strict hierarchy model there is a root CA, which has a self-
issued self-signed certificate and may issue certificates to lower-level CAs which, in
turn may issue certificates to end users. Then if B wants to verify the certificate of
another user A , he only needs a chain of trust from the root CA to A , for example
CA root
CA 1
A
meaning that CA root has issued a certificate to CA 1 which, in turn, has issued a
certificate to A . Of course, the chain of trust may contain more intermediate CAs
and, on the other hand, there are more general models than that with a single root
CA. These models may include multiple root CAs, mutually certifying CAs, and
other configurations.
Another trust model is the one used by web browsers which, as we have already
mentioned, come with a pre-configured set of CAs' public keys. There is no cross-
certification between these CAs but the browser itself acts as a sort of virtual root CA
for all of them because the user is trusting the browser company to include only valid
CAs. This model has several security weaknesses: for example, browsers usually
allow users—after being warned—to accept certificates that are not signed by one of
 
Search WWH ::




Custom Search