Certificate whitelist checking is a must. Usage of PKI-based digital certificates has become a widely accepted means of electronic identity authentication for all kinds of purposes, from logical and physical access control to document signing, server authentication for ecommerce sites and software code authentication.
Before relying on a digital certificate, it’s essential to check its current status to ensure it’s not revoked (e.g. security compromise, lost keys, cessation of operations etc.).
The Online Certificate Status Protocol (OCSP, RFC 6960) is a widely accepted approach for efficiently checking a certificate’s revocation status. OCSP client-side functionality is universally implemented in browsers, operating systems, networking devices and document software like Adobe Reader. Many vendors, including Ascertia, provide OCSP responders.
Attack vector
Traditional use of OCSP has an issue. It typically uses Certificate Revocation Lists (CRLs) to determine if a certificate is valid or revoked. CRLs are a black-list of revoked certificates, i.e. only identify those certificates which are known to have been revoked.
Recent attacks on well-known public Certificate Authorities (CAs) have resulted in fake certificates being issued by bypassing the normal CA software access control rules. For example, this is done by directly accessing the CA’s private signing key inside an HSM without being subjected to normal identification, authentication, access control and logging features of the CA software.
In such cases, the CA is not even aware that a fake certificate has been issued. As a result, these fake certificates can’t even be put on a CRL to indicate they have been revoked.
An OCSP responder, which gets its input feed from CRLs, can therefore not help to recover from such attacks. A traditional OCSP responder will return “Good” status for such fake certificates.
Fake certificates solution
To overcome the above attack, an OCSP responder should not just check whether a certificate is included on a CRL.
It must determine if the certificate was actually issued by the CA by looking at the CA’s database of issued certificates. This process is referred to as whitelist checking.
If the certificate is not found in the CA database of issued certificate, then the OCSP server should respond with a “revoked” status to prevent the certificate from being used (i.e. a fail-safe scenario).
The CA/Browser (CAB) Forum baseline requirements have been updated to make this a formal requirement from 1st August 2013.
13.2.6 response for non-issued certificates
If the OCSP responder receives a request for status of a certificate that has not been issued, the responder should not respond with a "good" status. The CA should monitor the responder for such requests as part of its security response procedures.
Effective 1 August 2013, OCSP responders must not respond with a "good" status for such certificates.
A new version of the OCSP specification has been released to cater for this, see RFC 6960. It formally defines the extended use of the “revoked” status to cover non-issued certificates. It also allows the OCSP responder to inform client applications that it supports this extended use by inserting a special extension in the OCSP response message.
Ascertia ADSS OCSP Server is one of the first OCSP responders globally to support this RFC 6960 whitelist checking mechanism and extension. ADSS OCSP Server returns revoked status for such non-issued certificates and allows real-time alerts to be generated and sent to configured administrators when such a non-issued certificate is encountered. This will help to quickly detect, analyse and resolve a potentially disastrous situation for a CA service provider!
