Design and build a privately hosted Public Key Infrastructure

Certificate revocation is the process of removing trust in a certificate issued within a PKI.

This may happen for a variety of reasons, such as a device being decommissioned, or a private key being compromised. End-entities become aware of revocation by checking with the validation authority.

Using certificate revocation will reduce the impact of a compromised certificate.

Any certificate revocation function should be centrally hosted and advertised in a highly available location. A Certificate revocation function could also be hosted in more than one location to provide a level of availability and redundancy.

Communicating revocation

There are three common methods of communicating that a certificate has been revoked:

• Certificate revocation lists (CRLs) are a list of revoked certificate serial numbers. The end entity will download and check the whole the list for a certain serial number, to ensure it's not been revoked.
• Online certificate status protocol (OCSP) operates by having an OCSP client (an end entity) which communicates with an OCSP responder to check if a certificate has been revoked. This method allows an end entity to check the status of a certificate without downloading a whole CRL.
• OCSP stapling is slightly different to OCSP. Instead of the OCSP client making the request to a responder, the OCSP request proving that the certificate is not revoked is presented by the server as part of a TLS handshake.

Choosing a revocation method

Here are a few things you may want to consider when choosing between protocols:

• CRL's will involve downloading and checking a whole revocation list, which in large environments or in certain network conditions, could be challenging.
• OCSP responders will need to respond to every request to a resource. On a busy network they need to scale to many requests.
• There are some privacy concerns raised with OCSP, as each revocation request to a resource is exposed to a third party.
• OCSP stapling is a newer protocol and, compared to OCSP and CRL is not as widely supported. OCSP stapling does improve on privacy and performance compared to OCSP.

This is not an exhaustive list of considerations when choosing a revocation method. The operating environment and application support will also be important factors.

The revocation function

The revocation function must be fully designed and implemented before issuing any certificates, as the revocation information need to be encoded into a certificate.

When designing a private PKI, the certificate revocation method must be updated and signed on a regular basis, otherwise a compromised certificate may not be advertised in a timely fashion.

Where practical, a Certificate Revocation Lists (CRL) signing key - a separate key, distinct from the CA signing key - should be used to sign the revocation list when deploying a CRL. Using a separate key for signing a CRL reduces the exposure of the CA's certificate signing key.

Fallback certificate verification

Another design consideration is how a device should react if it can’t access a certificate revocation service.

One option is to fail open. In this case, if an end entity cannot contact the revocation service, it will treat the certificate as not revoked.

The other option is to fail closed. In this case, the end entity will treat the certificate as revoked if it cannot contact the revocation service.

Deciding whether to fail open or closed depends on your availability needs, security requirements and available software support. You should assess this on a case by case basis.

Logging

Any certificate revocation should be logged in a central logging platform.