Nowadays, the security of computerized data is a foremost concern for any organization. To protect your company against data theft and potential attacks, technology based on public key methodology is available in a solution known as a Public Key Infrastructure, or PKI. The PKI’s role is to deliver digital certificates in order to ensure the confidentiality of the data contained in the system. The validity of a PKI certificate is managed by a certificate authority (CA), which checks to make sure an individual is authorized to possess the certificate in question.

Once a certificate has been validated, the CA signs that certificate using its root certificate. Root certificates are identified on a list that is available in each system that uses the PKI. This allows you to easily check whether a certificate has been approved by a certificate authority. You must nevertheless be cautious when verifying the certificate! If you only check the certificate’s signature without paying attention to the revocation date, the certificate will remain valid, and this could pose a problem in certain cases.

That’s why certificate revocation lists – CRLs for short – were invented! In most situations the CRL is sufficient, but limitations do exist in some cases, which led to the emergence of the Online Certificate Status Protocol (OCSP). So, there are two ways to find out a certificate’s status – by querying the CRL or using an OCSP responder – but what’s the difference?

CRL vs. OCSP – What’s the difference?

OCSP

A Certificate Revocation List (CRL) is a blacklist containing the IDs of certificates that are no longer trustworthy because they have been revoked or are invalid.  However, even if these lists are correctly managed by the relevant tools, the server’s response after processing the certificate contains a flaw: CRLs are generally refreshed approximately every 24 hours, resulting in a period of “uncertainty” between the certificate status query and the list’s publication date.

Here is an example:

  • CRL publication time: 01:00:00
  • Time a valid certificate’s status was queried in the previous CRL: 06:00:00
  • Uncertainty regarding certificate status: 5 hours

With today’s increasingly large number of high-value transactions that use certificates, coupled with the need to legally recognize electronic signatures, experts had to develop a service that would provide real-time information about a certificate’s status. This new protocol, named OCSP for Online Certificate Status Protocol, was designed to be a more effective and precise alternative to CRLs.

OCSP’s goal is to instantaneously verify the serial number of the certificate sent by the issuer in order to determine its validity using a whitelist. This alternative solution employs a query-response mechanism that asks the CA for very specific information. OCSP reduces the period of uncertainty between CRL publication dates and times to a minimum.

In practice, an OCSP request contains: the protocol version – the service requested – information about the certificate to determine its status – the extension supported by OCSP server as the signer of the request.

The signed response from the responder contains: the version of the protocol used to build the response – the response about the status of the certificate requested – the signature block – the certificate of the OCSP server queried – the time the response was produced – the exact time the response was provided (this information depends on whether the information is given in real time).

If the information is not sent instantaneously, additional information about the next update will appear, indicating when the certificate status can be verified. Depending on the client’s need, the OCSP service deploys different mechanisms to ensure the “freshness” of the information available to the responder being used.

Compared to traditional CRLs, OCSP offers several advantages, like providing information on the status of a certificate that is no longer up to date, and simpler processing which lightens network traffic.

OCSP in practice at IDnomic

The idea is clear: an OCSP service gives a certificate’s revocation status in real time. But this can be done in different ways, and IDnomic implements a range of options:

  • Option 1: Directly from the database;
  • Option 2: The server gives the certificate’s revocation status as indicated in the CRL, if the certificate number is included in the CRL;
  • Option 3: High capacity OCSP in the case of a request for several SSL certificates:
    • It is possible to put a cache on the application in order to respond to high demand from the platform without compromising response times (e.g. for OCSP requests concerning a frequently used certificate);
  • Option 4: Authenticated OCSP:
    • OCSP can be implemented via an authenticated access between the client and the platform;
  • Option 5: OCSP for eIDAS-referenced certificates:
    • The “archive cutoff” extension is directly incorporated into the platform and can be used to meet the requirements of qualified certificates;
    • Referenced cryptographic material that is eIDAS-compatible;

For optimal service, IDnomic combines OCSP with the Time Stamping Protocol (TSP). Used with a digital signature system and a time source, TPS delivers proof of time to the end client. This protocol can be used, for example, to attest to a document’s existence at a specific moment in time. In practice, a client sends a time stamp request to the platform – records the exact date and time – signs and transmits this information. The responses are signed using cryptographic material featuring an interface that complies with the PKCS#11 standard.

The verification of certificate statuses is a crucial phase in any process employed for signature authentication control or validation. Armed with this knowledge, at IDnomic we offer our customers a platform featuring both OCSP and TSP services: “Time Stamping Protocol!”