Certificate Revocation and Checking

When a CA Administrator determines that a certificate should no longer be trusted, for example if the certificate owner’s private key has been compromised, then that certificate can be revoked. Unlike the Valid To field that is a part of the each certificate, there is no way for the CA to locate every copy of a certificate that needs to be revoked and delete or mark them in some way. There must be some reference that users of certificates can check to determine current revocation status.

For digital certificates, there are three mechanisms used for status checking,

    • Certificate Revocation List (CRL)
    • Online Certificate Status Protocol (OCSP)
    • Identity Registration Protocol (IRP)

 

Certificate Revocation List (CRL):

In order to communicate about revocation the CA publishes a Certificate Revocation List (CRL). A Certificate Revocation List is a document contains the following items:

CRL

 

Version:  The CRL Version 2 (Defined in RFC 5280)

Issuer:  The CRL issuer

Effective Date:  The date and time that the CRL first issued

Next Update:  The date and time that the next CRL in sequence will be issued

Signature Algorithm:  The Public Key Cryptography Algorithm and the Hashing Algorithm that were used to sign the CRL
Authority Key Identifier:  This field gives additional information used to identify the issuer of the CRL
CRL Number: A unique identifier for the CRL

In order to make the CRL accessible the CRL is published to a repository.  These repositories are HTTP, HTTPS, LDAP or LDAPs repository.  They are then referenced in the CRL Distribution Point (CDP) Extension of a certificate.  A client that is checking revocation will first attempt to download a CRL from the first CDP location referenced in the CDP extension.  Once a CRL has been retrieved, it is cached until the nextUpdate date and time arrives, at which point the old CRL is discarded. When a cert is presented, the app checks the CRL cache for a still valid CRL. If none are found, it will obtain a new CRL at the specified URL and cache it with the new nextUpdate setting.

Online Certificate Status Protocol (OCSP):

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It was created as an alternative real-time protocol to address Certificate Revocation List (CRL) limitations. When CA supports OCSP, Clients can use OCSP to obtain up to the minute revocation status for any certificate.

Disadvantages of CRL and OCSP:

CRL requires a lot of complex functionality to process

Time-consuming method affecting cert reliability and Hackers can easily do a DoS attack

Not all CA’s supported by OCSP.

OCSP does not need to be encrypted, so when it discloses information about a particular node using some form of certificate to the responder, this information could be easily intercepted by third parties.

Identity Registry Protocol:

The Sixscape has a revolutionary discovery called Identity Registry Protocol (IRP). IRP is a well secured, XML-based request/response protocol. It addresses all those problems involved in CRL and OCSP since it is not layered over HTTP and does not involve Web servers/Web browsers. This allows to create a far more secure, efficient and stable protocol.

Certificate revocation is a standard operation in IRP. It just requires the certificate hierarchy and certificate serial number, and (assuming the authentication was successful), that certificate is revoked. That revoked status is available immediately via the IRP revocation status mechanism. Many clients do not have support for OCSP, and not all CAs have OCSP servers. It is possible that an IRP server could provide an OCSP server for clients that do understand that protocol.