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 ?

  • Your two points explain problems with embedding CRLs but your last sentence seems to ignore these and implies embedded CRLs are preferred. Did you misstate your hypothesis?
    – PwdRsch
    Commented Jun 16, 2015 at 18:29
  • Its the question. Can the embedded CRLs be preferred and used (as they are in a lot of validation tool) over online ones considering the 2 problems I stated. Will edit for clarification. Commented Jun 16, 2015 at 18:32

2 Answers 2


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).

  • Thank for the answer to CRL splitting. I suspect many validation tools does not take this Issuing Distribution Point into account OR this extension does not always appear in splitted CRL. As for my second question, I understand the "freezing" in time using a timestamp. My question is about a situation where a certificate is compromised after the "frozen" time but with a compromised date before that "frozen" time. Should this *AdES-compliant document be considered valid ? Commented Jun 16, 2015 at 19:46
  • 1
    The concept for that in *AdES is the "grace period": you use two timestamps, one on the signed object, then another one on the whole archive after, say, one week. The grace period is supposed to be sufficiently long that any compromise would have been detected in the mean time (if you prefer, the "grace period" represents a limit on how far back in time a CA may revoke a certificate retroactively). Commented Jun 16, 2015 at 20:22

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:

    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.

  • 1
    The CRL filename is arbitrary and not signed. I dont think we can effectively match on this without any doubts. Commented Jun 16, 2015 at 18:40
  • @MathieuFortin Good point. Commented Jun 16, 2015 at 18:42
  • OCSP responses fix the first issue since they contains the certificate validation was asked for. But since they also can be embedded, they do not fix the second issue. Commented Jun 16, 2015 at 18:43
  • @MathieuFortin Correct, anything which is embedded, or "stapled", or "pinned", has problem (2). If that's important to you, and you're willing to deal with the latency, then don't accept either stapled CRLs or stapled OCSP, force online checks. Commented Jun 16, 2015 at 18:46
  • (1) #29686 is about OCSP stapling in SSL/TLS (and especially HTTPS) not CRL embedding in a document like CMS, although the concept is similar. (2) @Mathieu if by "filename" you mean the URL in CRLDP, the CRLDP extension like all extensions is part of the signed certificate. Commented Jun 18, 2015 at 14:06

You must log in to answer this question.

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