Search code examples
javapdfdigital-signaturebouncycastlepkcs#7

LTV enabling signatures in PDF

As I understand there are two ways doing this by

  • adding DSS dictionary
  • embedding CRLs or OCSP responses in the signature at signing time

The DSS way seems to work and Adobe recognizes the signature as LTV enabled. The second way would fit much more into our application so I still try to get it to work. I'm having issues adding the OCSP responses to the signature so I only try to add the certificates and the CRLs. Correct me if I'm wrong but as I understand, either the CRLs or the OCSP responses should be added to the signature. There is no need for both? I collect the signing certificate and its root certificate, also the TSA certificate and its root certificate. After that, I fetch all the CRLs. All this is added before the signing and the timestamp. Adding only the certificates and the CRLs doesn't seem to work because Adobe doesn't recognize the signature as LTV enabled. I don't really understand what I'm doing wrong so any help is appreciated!

Store crlStore = new JcaCRLStore(crls); 
gen.addCRLs(crlStore);

Store certStore = new JcaCertStore(certList); 
gen.addCertificates(certStore);
Solution

  • What you're doing wrong is putting the CRLs into the CMS signature container element generally used for CRLs. In case of integrated PDF signatures, though, the situation is different; here CRLs are expected in a special signed attribute instead.

    Have a look at ISO 32000-1 where this attribute already is specified:

    The PKCS#7 object should contain the following:

    ...

    • Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature. This means that the software used by the signer must be able to construct the certification path and the associated revocation information. If one of the elements cannot be obtained (e.g. no connection is possible), a signature with this attribute will not be possible.

    ...

    12.8.3.3.2 Revocation Information

    The adbe Revocation Information attribute:

    adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
                              { adbe(1.2.840.113583) acrobat(1) security(1) 8 }

    The value of the revocation information attribute can include any of the following data types:

    • Certificate Revocation Lists (CRLs), described in RFC 3280 (see the Bibliography): CRLs are generally large and therefore should not be embedded in the PKCS#7 object.
    • Online Certificate Status Protocol (OCSP) Responses, described in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP (see the Bibliography): These are generally small and constant in size and should be the data type included in the PKCS#7 object.
    • Custom revocation information: The format is not prescribed by this specification, other than that it be encoded as an OCTET STRING. The application should be able to determine the type of data contained within the OCTET STRING by looking at the associated OBJECT IDENTIFIER.

    adbe's Revocation Information attribute value has ASN.1 type RevocationInfoArchival:

    RevocationInfoArchival ::= SEQUENCE {
  crl [0] EXPLICIT SEQUENCE of CRLs, OPTIONAL
  ocsp [1] EXPLICIT SEQUENCE of OCSP Responses, OPTIONAL
  otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo, OPTIONAL
}
OtherRevInfo ::= SEQUENCE {
  Type OBJECT IDENTIFIER
  Value OCTET STRING
}