What's the point of embedding Certificate Revocation List in PDF (CRL) rather than have pdf check online?

Question

I'm not understanding something. There's a concept called embedding the CRL in a pdf so that if my private key is stolen, I could report it to the CA and they would update their CRL on the web site. I've been reading that the purpose of embedding the CRL in a pdf is good for pdf files with many pages so that the pdf doesn't have to go online to and check for each and every page. Well, problem is, if the CRL is embedded in the pdf instead of having the pdf go check with the CA, then wouldn't it be impossible for revoked certificates to be discovered if the CRL is embedded in the PDF? Am I missing something?

Update: Even with a TSA time stamp, what is to prevent the thief from using old certificate and embed a CRL that doesn't say his certificate is revoked? This is what I don't get, that to me, the only assured way to prove doc is genuine is both TSA timestamp AND online OCSP. Otherwise, I don't see how an embedded CRL and TSA can ever be enough. With the CRL, it's like allowing the thief to say he is not a thief. Otherwise, there's some sort of misunderstanding on my part about embedded CRL.

Update2 10/1/2014 8:06am pst: Answer below. "CRLs at top level contain a datetime thisUpdate which indicates the issue date of this CRL. Furthermore it optionally may also contain a datetime nextUpdate" Is there a date and time for each revoked Certificate? A CRL can have many Certificates. If each revoked certificate doesn't have an invalid date, I don't see how it can be determined from what period the certificate and therefore signed document is bad. Answer, page 76 of the white paper does show what a Revocation List look like: it contains the serial numbers of the certificates along with the revocation date. this is how it's determines when the signed documents are bad. However, there appears to be gap of uncertainty after the last signed legit pdf to the time the certificate is reported stolen.

Thanks.

Answer 1

In a nutshell

If you report your key as stolen, it will be revoked at that very time (or even only at the time of the publishing of the next CRL). Thus, your earlier signatures are still considered valid.

If a current CRL is embedded into a PDF during signing, that information can be considered up-to-date for the signature during verification.

To make this work properly, a signature time stamp obviously is necessary, too.

In detail, CRLs

CRLs at top level contain a datetime thisUpdate which indicates the issue date of this CRL. Furthermore it optionally may also contain a datetime nextUpdate which indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. This second field actually is mandatory for CAs conforming to current standards.

Thus, if you embed a CRL in your integrated PDF signature which can be considered current at the time of signing (e.g. a CRL with a nextUpdate after the signing time), a verifier later can use this embedded CRL to deduce that the signer's certificate has not been listed as revoked at the time of signing.

Actually the verification process does not require an independent verifier with his own CRL caches either to update if he already has a CRL with a nextUpdate after the signing time unless the certificate or the CRL contains the freshest CRL extension.

So your worries

if the CRL is embedded in the pdf instead of having the pdf go check with the CA, then wouldn't it be impossible for revoked certificates to be discovered if the CRL is embedded in the PDF?

only indicate a problem for signatures created between the time of the theft and the scheduled issuing date of the CRL update which includes your theft report.

And these signatures will always be a problem for you because they might also be positively verified during that time using other means and result in legal consequences. (So this is why you should choose a CA which re-issues CRLs in short sequence.)

As this verification process heavily relies on the signing time being assured, a signature time stamp is necessary to serve as ascertained source for the signing time.

The same is true for OCSP responses, by the way, they also contain thisUpdate and nextUpdate fields. The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. OCSP responses can likewise be embedded in PDFs.

But how would the system know the earlier signatures (say 1/2014) are still valid? I mean, say you stole my key and used it (say 9/2014), then how does the system distinguish between my legit prior signing of docs (9/2014) vs my docs (1/2014) since we would use the same certificate?

CRLs (and OCSP responses) contain the datetime revocationDate, the date on which the revocation occurred. Signatures from before that date still have to be considered valid (as far as revocation is concerned). As mentioned before, signature time stamps are a necessity for this to work properly.

By the way

You've

been reading that the purpose of embedding the CRL in a pdf is good for pdf files with many pages so that the pdf doesn't have to go online to and check for each and every page.

That is weird, and in general it does not make sense.

No matter how many pages a PDF document has... if you sign it, a single signature suffices to sign the whole document at once. And after that signature you generally are not free anymore to add additional pages to the document.