pdfpdfboxsignature

How to add VRI dictonary into a PDF

there! I'm using pdfbox 1.8.11 to do pdf signature, I could create a LTV-enabled signature with DSS dictionary embedded. Now the problem is the certificate verification when there are multiple signatures.

According to PDF 2.0 LTV and PAdES LTV specification, it is allowed to add VRI for each signature, so that it is possible verify related revocation data for each specific signature.

Any idea how to add VRI dictionary for the signature? As the key for VRI is the a base-16-encoded hash, which means I need to have signature first. As far as I know (I hope i was wrong), the signature is created when the PDF with signature related information is saved into output stream. (PDDocument.saveIncremental(ins, outs))

============================================================

more in detail:

I ran into this problem when I want to verify the signature against DSS data according to the PAdES LTV and PDF 2.0 LTV specification. First focus is the PDF 2.0 LTV specification.

If i understand correctly:

  1. The DSS contains revocation data for all signatures we have in the signed PDF.

The situation I ran into: Assume: there are two users User A and User B, their certificates are issued by the same CA:s. (It's quite common I think. )

  1. User A signed the document with DSS (certs/crls/ocps are embeded).
  2. Days later, User B sign the User A signed document with DSS (certs/crls/ocps). Note!: crls are identified by issuer identifier.

Signature verification phase:

When I want to rebuild the certificates chain, verify the sign certificate against the crls and ocsps, especially when I want to check the crl is not expired at the time when the document is signed, I need to make sure I'm using the right version of crl.

To me, it means I should check certs/crls/ocsps correctly mapped with the signature. Otherwise the verification is reliable any more, equally meaningless.

Therefore, even though the latest PAdES specification 103 does not recommend to use VRI. Seriously, I think it is not right....

Then another problem:

As I commented bellow, I'm using pdfbox to sign pdf.

  1. If I collect DSS data beforehand, create the signature afterwards. (The fact is that the DSS is also part of the signed content.)

    • Good thing: acrobat reader recognize my signature is LTV enabled.
    • Bad thing: in such situation, I'm not able to add VRI there. The key for VRI is hashed value of the signature.

  2. If I sign the document first, got the signature and DSS with VRI afterwards, acrobat reader does not recognize the DSS any more. My signature is no longer LTV enabled to acrobat reader. It is the problem I'm confused. Is acrobat reader wrong in LTV verification or ??

Do I think it wrong? If anything I understood wrong, please do point it out. Thanks in advance!

Solution

  • First of all, the latest PDF 2.0 draft I've looked through is some two years old. Thus, my answer had better be based on the ETSI standards and not on that draft. ;)

    If i understand correctly:

    1. The DSS contains revocation data for all signatures we have in the signed PDF.

    Not necessarily for all signatures. If a verifier is interested in the validity of a single signature only (a likely scenario if the signatures in a document have different semantics), it should nonetheless add the acquired validation related information.

    When I want to rebuild the certificates chain, verify the sign certificate against the crls and ocsps, especially when I want to check the crl is not expired at the time when the document is signed, I need to make sure I'm using the right version of crl.

    To me, it means I should check certs/crls/ocsps correctly mapped with the signature. Otherwise the verification is reliable any more, equally meaningless.

    What exactly is your aim? Do you try to re-enact a specific former verification act? Or do you simply want to verify a signature?

    In the former case you indeed need some mapping "for verifying this signature the following validation relation information was used" given by e.g. the VRI structures.

    Usually, though, the latter is your task, and in that case you can use any validation related information you find as long as it applies. Thus, in your sample situation of signer certificates issued by the same CA, you can use the same CRL as long as the CRL validity interval is ok for both validation times of the signatures and the signature of the CRL itself can be positively verified.

    Thus,

    Therefore, even though the latest PAdES specification 103 does not recommend to use VRI. Seriously, I think it is not right....

    The PAdES specification on LTV merely wants to guarantee that signatures can be verified, not that they can be verified exactly as before. With this task in mind, it is right.

    If I collect DSS data beforehand, create the signature afterwards. (The fact is that the DSS is also part of the signed content.)

    Good thing: acrobat reader recognize my signature is LTV enabled.

    Bad thing: in such situation, I'm not able to add VRI there. The key for VRI is hashed value of the signature.

    You are not only not able, you actually are not allowed! As ETSI EN 319 142-1 V1.1.1 puts it:

    Any VRI dictionaries shall be located in document incremental update sections. If the Signature Dictionary to which a VRI dictionary applies is itself in an incremental update section (see clause 7.5.6 of ISO 32000-1 [1]), the VRI update shall be done later than the signature update.

    If I sign the document first, got the signature and DSS with VRI afterwards, acrobat reader does not recognize the DSS any more. My signature is no longer LTV enabled to acrobat reader. It is the problem I'm confused. Is acrobat reader wrong in LTV verification or ??

    This is where an example file showing this behavior would help