Can an embedded CRL be trusted?

Question

Embedding CRLs in a signed document will allow the signature to be validated "long term", by providing a snapshot of the signer's state the moment the document was signed. Im wondering if these embedded CRLs can be trusted since:

1. Some PKIs will allow issuance of multiple small CRLs. Embedding one of these CRL will produce perfectly valid documents, even if the embedded CRL is not the one where the certificate will ultimately appear. From a client perspective, there is no way to tell if a PKI uses multiple small CRLs or a single one where every certificate appear.
2. Signer state at time of signature can change post-signature. Let's define: T as the moment a valid signature was made and a corresponding CRL embedded. T+1 as the moment the certificate was revoked. T-1 the time set as the actual revocation date (ie compromise date in the past, before the signature was made). From T to T+1, the signature should be valid. After T+1, the signature should be considered invalid since the key was compromised at time T-1. In this situation we cannot rely on the embedded CRL as it will always show the signature as valid. On the other hand, online verification can only be used up until the certificate expiration. Afterwards we are only left with the embedded CRL, which we know is missing some important bits.

So, in this regard, can we prefer embedded CRLs over online ones ?

Answer 1

A CRL has value, and is acceptable, by virtue of being signed. Since the CRL is signed, how you obtained it is of no consequence whatsoever on its acceptability. That's the point of certificates and CRL: they can be distributed over arbitrary networks, protected or not, even plain HTTP, email, avian carriers... it does not matter.

Conversely, that the CRL is "online" does not make it any better; you still have to verify the signature, dates and so on.

Thus, CRL (or certificates, or OCSP responses) can perfectly be embedded, transmitted along with the data they qualify, or whatever. For instance, a CMS (PKCS#7) SignedData object contains fields called certificates and crls precisely to embed certificates and CRL (and OCSP responses) that receivers of such an object may find useful for validation purposes. In a similar vein, when a SSL/TLS server sends its certificate, it sends also some extra certificates (a "chain") that the client may use (at its leisure) to validate the server's certificate.

---

When a CA splits the CRL into multiple sub-CRL, the scope of each CRL is explicitly indicated: a certificate is in the scope of a CRL if the certificate contains a (critical) CRL Distribution Points extension with a "Distribution Point" that matches the Issuing Distribution Point extension in the CRL. See RFC 5280, section 6.3.3, step (b).(2).(i). This CRL splitting is thus not a problem.

An even more extreme splitting is incarnated by OCSP. OCSP is both a format for signed objects (the "OCSP responses"), and a communication protocol to obtain an OCSP response from an online responder. Each OCSP response is functionally equivalent to a CRL that talks about a single certificate. Thus, this is like the most split CRL that you can imagine, and yet it does not create any ambiguous information because each OCSP responses designates explicitly what certificate it is talking about.

Therefore, that a CRL is split or not does not induce any weakness; and obtaining fresh CRL from the CA would not fix anything either, since the downloading process is not protected anyway.

---

As for your second question: indeed, revocation status is, by definition, a transient property. On the one hand, that the signer's certificate was unrevoked at some point in the past (that's the information provided by an old CRL) does in no way guarantees that the certificate is still unrevoked, and, in particular, that the private key was not compromised in the mean time. On the other hand, recent CRL don't talk about expired certificates (and that's the point of certificate expiration: to prevent CRL from growing forever).

The exit out of this conundrum is time stamps. With a time stamp, you can somehow "freeze" an object at a moment in time. The idea is that, at date T, you take the signed object, along with all certificates and CRL that can be used to validate the signature at that date. You put all of these in some archive format, then obtain a time stamp on the whole. At a later date T', you validate the time stamp; if the time stamp is valid (at date T'), then you know that all the archive contents already existed at date T, and you can then proceed to validate the signature and use the certificates and CRL as if the current date was still T. The concept is that IF you had done the validation at date T, THEN you would still remember it, and act upon it; with the time stamp, you know that at date T all the certificates and CRL existed as is, and thus you could have done that validation.

There are a lot of subtleties in that process, which is why some standards have been defined to support it properly. Look up CAdES (and possibly its brothers XAdES and PAdES, for XML-DSig and signed PDF, respectively).

Answer 2

I believe the general name for this is CRL Stapling, which might be a useful google search term for finding your answer. Here is an excellent security.SE question explaining CRL Stapling.

Some thoughts on your question:

1. Even if a CA is configured to publish multiple small CRLs, each certificate includes an extension which points to the CRL file in which it will be revoked. For example, the certificate for *.stackexchange.com includes this extension:

   [1]CRL Distribution Point
   Distribution Point Name:
     Full Name:
          URL=http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
   

   From the filename, I would guess that this is the 2nd CRL file in a set of small(ish) CRLs. When a client app is verifying a stapled CRL, it could check that the filename matches the CRL Distribution Point in the cert.

2. Correct. You have identified a major downside in CRL stapling. There is no solution to this.

Nobody ever claimed that CRL stapling was more secure than online checks, it is not. What it does offer is speed since no online checks are required. As you point out, many software vendors are willing to make this speed-over-security tradeoff (and I can't blame them since some CAs can take tens of seconds to respond to an OCSP request, and/or published CRL files are days old).

For this, and other reasons, the industry is (slowly) moving away from CRLs towards the Online Certificate Status Protocol (OCSP) and other technologies for propogating revocation information.