How to add VRI dictonary into a PDF

0
votes

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!

1
pdfpdfboxsignaturedss
Any idea how to add VRI dictionary for the signature? - Have you tried anything yet? ... Now the problem is the certificate verification when there are multiple signatures. - Why is that a problem? – mkl
Well, honestly, I definitely tried. I might do not figure out to use it in right way. So if any hints, I will appreciate so much. The VRI key for each specific signature is base16 hashed signature, right? 1. The signature is created when the document.saveincremental() is called, which means it will write into real disk file. 2. I need to add DSS based on this file, which is already not in the same content scope. (So far, I added DSS with full needed certs/crls/ocsps, acrobat reader doesn't recognize the signature as LTV enabled any more.) – ryuukei
yes, you are right. it is possible to add DSS which contains VRI there, my concern is that Acrobat reader doesn't recognize it when I added the DSS later on. – ryuukei
If you start from scratch, it would be better to use the 2.0.* version and not the 1.8.* versions. – Tilman Hausherr
@ryuukei First of all, Adobe Acrobat does not require you to use VRI information. That would be a bad idea indeed, after all ETSI in its newest PAdES norms recommends against using VRI!Thus, missing VRIs are not the problem you ran into. You probably had best share a sample PDF you signed with what you consider full needed certs/crls/ocsps for us to analyze. – mkl

1 Answers

0
votes

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