2
$\begingroup$

RFC 5280 states that the CRL number should monotonically increase. I have seen this common practice of incrementing the CRL number by 1, every time a new CRL is generated. But can I use a Unix (epoch based) time stamp as the CRL number, which is monotonically increasing ?

$\endgroup$
  • $\begingroup$ advantage of counter: you can be sure to not have missed a CRL in between. $\endgroup$ – SEJPM Mar 11 '16 at 11:31
2
$\begingroup$

Using a time stamp is certainly allowed, provided it is truly monotonically increasing. What I want to point out here is that computers have knowledge of the current date and time through their internal clock, which may be subject to drift and therefore to alterations to put it "back in line". Some systems will rely on NTP, a network protocol which is not the most secure protocol ever (in fact, base NTP is completely unauthenticated, thereby active attacker may fool with your clocks to some extent). Other CA, that try to work without relying on an unsecured network protocol, may be subject to heavy drifting over time, thereby requiring an occasional manual reset. Both the drift and the risk of human error may induce the CA into issuing a CRL with a non-monotonic number, which is a problem.

Another point to take into consideration is that "relying parties" (the systems that will read and process your CRL) may convert CRL numbers into relatively small integers, under the (faulty) assumption that "MAX" means "fits in a signed 32-bit integer". Beware of Year 2038! This would not be, technically, your fault (the RFC is clear in that respect), but it would still impact the already flimsy support for revocation.

For these reasons, a CRL counter, that is updated and saved across reboots, seems to be a better idea, from an engineering point of view.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.