While studying a security course I have been asked this very question:
Why are CRL periodically renewed, even if there are no new revoked certificates to add to the list?
Honestly I can't find the answer, if any of you could be so kind to shed some light on it, I would be very grateful.
A couple fundamental things:
The basis of a CRL is a promise for a certain time period. That means a begin time and an end time. Once a CRL is made and signed, it can't be changed, so it lasts as long as it lasts, and can't be trusted after that.
In essence, you won't know until you check. A CRL in its regular form is one big list. You can't assume that the size is an indication... the verifier needs to know exactly what Certificates are no longer trusted. So you need to get a fresh copy, either way. There's no protocol to check "is this the same as my old one?"
The primary implementation of CRLs is not "go get one when you need it" but "get it ahead of time, and check it when you need to". Which means the primary mechanism of distribution is a series of file downloads and caches. A server won't know that the next CRL is exactly the same as the currently expiring CRL until it has both - at which point, if you have a fresh version, why check? If what is needed is a "ask when you need it, you'll always have access" sort of structure, then go with OSCP.
The basic rationale of validity dates is to allow PKI implementers to make a conscious decision about how long to go with out checking in with the CRL issuer. A PKI system will make this decision on an issuer by issuer basis, in accordance with the risk to the system and the patterns of its intended usage. It's a real challenge - the validity should be commensurate with the risk - how long are the system protectors willing to wait before checking in on the "known bad guy" list?
There's a basic premise here that I relate to looking at canned food in a submarine... the expiration date is how long the manufacturer promises that it'll be OK to consume it. Can you eat meat a day after the expiration date? Yep. In fact, day-old meat is a way better option than starving to death. What about meat that is 6 months past it's expiration date? Well.. what kind of germs are you up against? There's a real possibility that this food will make you sicker than not eating anything (just shutting down and doing no transactions until you have a fresh CRL). In all cases, the reality is, you weight the cost of doing business against the risk of uncertain data.
NOTE: All this applies only to a general, garden variety CRL. There's a number of alternate formats out there. Last I looked, they were all proprietary... but it's been a while... some of these alternate formats can work differently, as they all aim at simplifying.
A certificate revocation list (CRL) is a time-stamped listidentifying revoked certificates that is signed by a CA or CRL issuerand made freely available in a publicrepository.Each revoked certificate is identified in a CRL by itscertificate serial number.
When a certificate-using system uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the certificate signatureand validity but also acquires a suitably recent CRL and checks hat the certificate serial number is not on that CRL.
The meaning of "suitably recent" may vary with local policy, but it usuallymeans the most recently issued CRLA new CRL is issued on a regular periodic basis (e.g., hourly, daily, or weekly).
An entryis added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyondthe revoked certificate's validity period.
An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves, namely, via untrusted servers and untrusted communications.CRl's would revoke when private key of an asymmetric encryption key pair (whose public key has been certified by the CA) is stolen.In such a situation, anybody with the private key could decrypt all communication between a user and the certified entity.
CRLs Will be issued periodically, in which case certificates that have expired may be tagged as revoked, or they may be issued as soon as a certificate is revoked. To keep CRLs from being faked, they are signed by the public key of the CA and contain a timestamp, after which the CRLs themselves expire.
Reasons for revocation :
According to ietf the common reasons for revocation were :
keyCompromise
CACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
removeFromCRL
privilegeWithdrawn
AACompromise
In the X.509 model, there is no restriction on download. When a verifier (say, a Web browser) wants to validate a certificate, it will try to obtain extra information through other objects: certificates, CRL... and it may obtain these objects over insecure channels. That's the point of CRL being signed: a verifier will trust a CRL not because it just obtained it from a specific Web site, but because the CRL is signed by an authorized CRL issuer (usually the CA itself).
The bright side of such a principle is that it makes X.509 certificates applicable to all kinds of networks. Otherwise, you would have a rather harsh chicken-and-egg problem: how would you trust that you got the right, most recent revocation information ? Because you downloaded it from a HTTPS server ? But how did you verify the certificate of that server ? And so on...
But there is a dark side, of course: a CRL is a snapshot of revocation information at a given date. Being signed, it is immutable. It cannot be changed. It is thus always a bit stale. A verifier will require that the CRL it uses are "not too old" -- and that, inherently, implies regular publishing of newer CRL.
On the technical point of view, we may envision a specific kind of CRL which does not contain the whole list of revoked certificates (which can be bulky) but only a short message stating "no certificate revoked since that date", thus allowing to somehow extend the lifetime of a CRL. This exists; it is called delta CRL. With delta CRL, a new CRL is virtually emitted at regular intervals, without necessarily forcing the download of a new big file.
Unfortunately, not all software out there know how to use delta CRL.
Another technique is segmentation: split the CRL into many smaller files, each talking about only a subset of certificates. Down that road lie very small CRL which assert the revocation status of only one certificate at a time; this is known as OCSP. There again, support is in deployment.
