2

I have two questions regarding the safety of requesting CRLs.

  1. My first question is: shouldn't CRLs contain a producedAt field just like OCSP responses? This would make sure a hacker doesn't send an old (but not yet expired) CRL to the client, right? Why isn't this done? Is it because CRLs are bigger and signing them each time would cost too much time? Or is it because CRLs are seen as static files (which wouldn't be a really good reason)?

  2. Then my second question. I've seen my browser requested a CRL with an HTTP If-Modified-Since header. The server responded with a 304 - Not Modified code. Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
SWdV
  • 179
  • 11

1 Answers1

2
  1. [...] is it because CRL's are seen as static files [...]?
  1. Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?

Yup. Both limitations are known. And from how I read the RFC, both are deliberate design choices.

From RFC 5280, section 3.3 Revocation: (emphasis mine)

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.

One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until all currently issued CRLs are scheduled to be updated -- this may be up to one hour, one day, or one week depending on the frequency that CRLs are issued.

###Further reading

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86