Enrollment – Digital Certificates and Certification Authorities
10.2.3 Enrollment
The process by which Alice obtains a certificate from a CA is called enrollment. There are various options for doing this, but in the most common scenario, Alice first computes a key pair (PKAlice,SKAlice). She then generates a Certificate Signing Request (CSR) and sends it to the CA. The CSR is signed by Alice and contains the following data:
- Alice’s DN
- Public key info (public key algorithm and public key)
- Intended key usage (the CA does not have to adhere to this usage)
- Signature algorithm OID
- Signature value
Upon receipt of the CSR, the CA first verifies the signature by using the public key contained in the CSR, thus making sure the CSR is a valid request. The CA then has to make sure that the information given within Alice’s DN is correct. For example, Alice could be requested to appear in person at the CA’s so-called Registration Authority (RA) and to authenticate by means of a passport. However, other, less costly (and less secure) options are available. Which option is used by the CA for which type of certificate can typically be found in the certificate policy.
After the CA has successfully verified Alice’s identity, the certificate is generated and sent to Alice. Since the certificate contains no secret information, it can be made publicly available by the CA.
10.2.4 Certificate revocation lists
We have seen that each certificate comes with its own validity period, after which a certificate will automatically become invalid. But sometimes it becomes necessary to invalidate a certificate, although the validity period has not expired yet. This process is called certificate revocation.
The most dramatic reason for certificate revocation could be a private key compromise at Alice’s site. This means an attacker can sign in Alice’s name and the only way to stop this impersonation attack is to invalidate the certificate, so that signatures using this key can no longer be verified. In most cases, however, the reasons for certificate revocation are more mundane, for example, the DN of the certificate owner could have changed, for example, because of marriage or change of affiliation.
In practice, Alice and her CA will agree on a revocation password, which Alice can provide via an offline channel, for example, telephone, to the CA. The CA will then add the serial number of the certificate to a Certificate Revocation List (CRL), a signed list of revoked certificates along with the reasons for revocation (see Figure 10.3).
Figure 10.3: A certificate revocation list
There are, however, a few drawbacks associated with using CRLs. They include each and every certificate that has ever been revoked during the operation of the CA, so they can be rather long and contain a lot of irrelevant information. Moreover, they are typically updated once a week, so it could be seven days until a revoked certificate appears on it. Finally, if the private key of a CA gets lost, all certificates issued by this CA are supposed to be put on the CRL. However, it is not clear how this should work with a compromised CA. For this reason, browser manufacturers such as Google or the Mozilla Foundation are moving away from CRLs.