PDF Signature - LTV - CRL alternative?

Question

I'm working on a .NET PDF signature application that allows signing with a SmartCard (Belgian ID). In addition, I'd like the signature to support LTV.

I've followed the instructions and examples from iText, and it seems to work well. Acrobat Reader DC indicates that the signature is valid, and offers LTV.
There is an practical issue however: the included CRL is too big. 14MB on my test ID. This means that, for every signature, 14MB needs to be downloaded which slows down operation and significantly increases the file size of each signed PDF.

I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality, however simply removing the CRL and including a OcspClientBouncyCastle instance didn't do the trick. Is the OCSP that is given to SignDetached used to check whether the certificate is revoked at time of signing instead?

A related question concerns the LTV "support" itself. As I mentioned, Acrobat Reader only indicates that the file supports LTV when the CRL is included. Checking at the online service http://dss.nowina.lu/validation (EU reference) seems to indicate something else however. There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data"). As such, I was wondering if it is even needed to include the CRL for LTV?

Suffice to say I'm confused :).

Btw, 2 more warnings from that same verification service that I can't seem to solve: "The 'issuer-serial' attribute is absent or does not match!" and "The signer's certificate is not supported by SSCD!". But maybe thats for another question.

Thanks in advance for any help.

Answer 1

I had a look at your sample document. It does not conform to any LTV profile, merely to T-Level, i.e. it is timestamped.

In detail

The PDF signature is implemented merely by embedding a single CMS container using subfilter ETSI.CAdES.detached which contains

• the certificate chain of the signer certificate in the CMS container certificate set

  • C=BE,CN=Belgium Root CA2

  • C=BE,CN=Citizen CA,SERIALNUMBER=201103

  • C=BE,CN=Donny Tytgat (Signature),SURNAME=Tytgat,GIVENNAME=Donny Geert,SERIALNUMBER=81032305309);

• a signed Adobe RevocationInfoArchival attribute containing a single good OCSP response for the signer certificate; the response is signed by

  • CN=Belgium OCSP Responder,C=BE

  which has the id-pkix-ocsp-nocheck extension;

• a signature time stamp signed by

  • C=BE,SERIALNUMBER=2014,O=Belgium Federal Government,CN=Time Stamping Authority

Thus, the signature conforms to Baseline T-Level as

A PAdES signature conformant to T-Level shall be a signature conformant to B-Level for which a Trust Service Provider [i.4] has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually existed at a certain date and time.

(section 7 - Requirements for T-Level Conformance - ETSI TS 103 172 V2.2.2)

where B-Level conformance is defined as

This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil. The current clause specifies compliance requirements for short-term electronic signatures.

This clause actually profiles PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures that do incorporate signature-policy-identifier) signatures.

(section 6 - Requirements for B-Level Conformance - ibidem)

(Additional requirements also are fulfilled.)

---

It does not conform to LT-Level which requires:

The generator shall include the full set of revocation data (CRL or OCSP responses) that have been used in the validation of the signer, and CA certificates used in signature. This set includes all certificate status information required for validating the signing certificate, for validating any attribute certificate present in the signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) already incorporated to the signature.

(section 8 - Requirements for LT-Level Conformance - ibidem)

as there is no revocation information concerning the CA certificate or the TSA certificate.

Thus, it can also not conform to LTA-Level as

A PAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more document-time-stamp has been incorporated

Concerning other questions

I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality

Given an appropriate PKI infrastructure that is possible. Unfortunately, though, neither the CA not the TSA certificate contain information on a OCSP responder responsible for them. Thus, either the Belgium citizen PKI does not provide OCSP services for those certificates or it merely does not make that provision public.

BTW, this is what the Diagnostic Tree remarks

<Message Id="0">OSCP Uri not found in certificate meta-data !</Message>

are about which you get when verifying your signature using the http://dss.nowina.lu/validation service.

There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data").

This user interface layout has misled you, as mentioned above there are more requirements for LTV-related profiles.