I have a question about DeltaCRL with an entry which contains RemoveFromCRL reason.
At the start, PKI has revoked the certificate with certificateHold reason.

And create next CRL:

Last Update: May 28 13:14:09 2015 GMT 
Next Update: Jun 27 13:14:09 2015 GMT
Revoked Certificates:
    Serial Number: 12
    Revocation Date: Aug 14 14:44:00 2014 GMT 
    CRL entry extensions:
            X509v3 CRL Reason Code: 

Later, our PKI unrevoked the certificate, removed the certificate from CRL and created next Delta CRL:

Last Update: May 30 12:51:40 2015 GMT 
    Next Update: May 30 15:00:00 2015 GMT
    Revoked Certificates:
        Serial Number: 12
        Revocation Date: May 30 12:51:40 2015 GMT 
        CRL entry extensions:
                X509v3 CRL Reason Code: 

What value can I use for RevocationDate for DeltaCRL and why?
I should use current time or revocationDate from first revocation?

1 Answer 1


The 'removeFromCRL' reason code indicates that the certificate is, in fact, not revoked. The idea behind 'certificateHold' is to make a suspension, not a revocation: the PKI declares that the certificate should not be used until more information is made available (in a subsequent delta or full CRL), while not fully revoking the certificate, because revocation is a one-way trip. In that sense, the certificate was never revoked, and thus was not "unrevoked" either.

This implies that the "revocation date" for a 'removeFromCRL' code is completely ignored. That date qualifies the instant from which the certificate should be considered as revoked, until the end of times; the 'removeFromCRL' code cancels that.

If you look at RFC 5280, you will see that the revocation date is not used at all in the validation algorithm. Its main purpose is to support past validation, when you want to know whether a given certificate was valid at some past date (this is used in some signature formats, in conjunction with time stamps). When a CRL lists that a certificate has been revoked at date T, this means that after date T the certificate must not be considered as valid, but also that before date T is was fine. For instance, if the certificate was on a smart card that has been lost, then the "revocation date" should be the last time at which the smart card was last seen by its owner, since at any ulterior date the card might be in the wrong hands. For the certificateHold/removeFromCRL pair, the point is that the private key was never compromised and the certificate never revoked, so there is no "revocation date".

(Arguably, the 'certificateHold' and 'removeFromCRL' reason codes are a hack which encourages PKI owners to use revocation as an emergency suspension mechanism, i.e. a substitute for authorization, and that is a bad idea. Revocation is, by nature, an asynchronous mechanism, and does not work well for that. When a situation arises where you would want to put a certificate "on hold", the sane thing to do is to revoke the certificate and issue a new one.)

  • Can you comment on the "Invalidity Date" extension? Doesn't this do the same thing? Commented May 31, 2015 at 14:58
  • When present, the Invalidity Date extension contains the date from which the certificate should be considered invalid. But this extension is optional, so when it is not present, the revocation date (which is not optional) has to be used instead. Commented May 31, 2015 at 15:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .