Use HTTP over Transport Layer Security (HTTPS) for the revocation list distribution points (CDP) and the online responder (OCSP).

With regard to the design of the infrastructure for providing revocation information - i.e. the CRL Distribution Points (CSP) as well as the Online Responders (Online Certificate Status Protocol, OCSP) - the question arises whether these should be "secured" via Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

Sometimes it is necessary for a certificate issued by a certification authority to be withdrawn from circulation even before its expiration date. To make this possible, a certification authority keeps a revocation list. This is a signed file with a relatively short expiration date, which is used in combination with the certificate to check its validity.

The Online Responder (Online Certificate Status Protocol, OCSP) is an alternative way of providing revocation status information for certificates. Entities that want to check the revocation status of a certificate do not have to download the complete list of all revoked certificates thanks to OCSP, but can make a specific request for the certificate in question to the online responder. For a more detailed description, see the article "Basics Online Responder (Online Certificate Status Protocol, OCSP)„.

Often, companies are also required by compliance guidelines to map all HTTP-based connections via SSL/TLS. This also raises the question of whether and how this should be implemented for CDPs or OCSP, since both methods rely on unencrypted and thus supposedly insecure HTTP.

To answer this question, let's first take a look at the relevant RFCs on this topic. For the revocation list distribution points, this would be the RFC 5280:

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies. CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server's certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

For the Online Certificate Status Protocol we find the corresponding passage in the RFC 6960:

Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

Conclusion

Neither RFC prohibits the use of SSL/TLS. However, RFC 5280 explicitly warns against it. The reason is as follows:

If SSL/TLS is used for the revocation information, a corresponding certificate is required. This will in turn contain revocation information that must be checked so that the certificate is recognized as valid.

This creates an unresolvable dependency (if you want to use SSL/TLS throughout). The only way to resolve this is to map the last revocation list distribution point in the chain without HTTPS again.

Thus, the supposed advantages of HTTPS do not apply in this case.

However, since the revocation information is signed by the certification authority or the online responder anyway, both when using revocation lists and OCSP, and is thus protected against manipulation, there is no reason for using HTTPS in this case, even apart from the problem with the unresolvable dependencies.

Related links:

External sources

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
• RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (Internet Engineering Task Force)