Low level workflow to achieve PAdES LTV digital signatures in PDFs

Question

I'm trying to figure out the low level workflow within a pdf to digitally sign and make it PAdES LTV compliant. I can digitally sign but it's the timestamping and OSCP response worflows i'm yet to fully figure out where to add these. This is the flow i'm struggling with so far:

• Add a placeholder for the signature with CAdES subfilter .. Do i need to also create an empty DSS store during this step? or while signing?

• Sign a pdf to create a signature with the users private key, which embeds the cert in the signature, and replaces the contents in the signature dictionary with the signature (i have this working)

• Send the signature? (or do i send the byte code hash?) to a TSA, which adds a timestamp, creates a new hash, and signs using the TSA private key.

• Where does the timestamp signature go within the PDF objects? overwrites the contents? somewhere else? I see a /Timestamp seed value in the pdf docs

• The TSA certificate is added to the DSS store

• Repeat the process above for the OSCP response, again where does the OSCP signature go? or is it a case of building up the signature within the contents value, eg

1. signers digital sig
2. signers digital sig + timestamp (signed by TSA)
3. TSA digital sig + OSCP response (signed by OSCP)

Add the third sig into contents and decrypt backwards while validating LTV?

Thanks

Answer 1

As clarified in comments you are talking about compliance with the PAdES baseline B-LTA profile (ETSI EN 319 142-1).

First of all, please remember that the baseline profiles are specified to allow extension to the higher profiles, so B-B can be extended to B-T and up, B-T can be extended to B-LT and up, and B-LT can be extended to B-LTA.

Thus,

• Add a placeholder for the signature with CAdES subfilter .. Do i need to also create an empty DSS store during this step? or while signing?

There is no need for DSS objects at this time. At this time you are in the process of creating a B-B (or maybe B-T) profile signature. There is no requirement for DSS before B-LT, see section 6.3 of ETSI EN 319 142-1.

• Sign a pdf to create a signature with the users private key, which embeds the cert in the signature, and replaces the contents in the signature dictionary with the signature (i have this working)

Ok, now you have compliance with PAdES B-B.

• Send the signature? (or do i send the byte code hash?) to a TSA, which adds a timestamp, creates a new hash, and signs using the TSA private key.

• Where does the timestamp signature go within the PDF objects? overwrites the contents? somewhere else? I see a /Timestamp seed value in the pdf docs

Here you want to go from PAdES B-B to B-T. For this you actually have a choice:

• You can add a signature time stamp to the CMS signature container you just injected into the PDF. Obviously you can only do so if you had initially chosen the Contents value placeholder large enough to hold this extra data.

  The details for adding a signature time stamp attribute are explained in ETSI EN 319 122-1 (CAdES) and RFC 3161. In particular, the value of the messageImprint field within the TimeStampToken shall be the hash value of the signature field (without the ASN.1 tag and length) within SignerInfo for which the signature-time-stamp attribute is created.

  Thus, if your time stamp service works as a RFC 3161 server, you have to send the hash of the signature bytes in the SignerInfo of your CMS signature. If your time stamp service implements a different protocol, you have to check the specification of that protocol.

• Alternatively, you can add an incremental update with a document time stamp to your PDF with the B-B signature. This does not require any extra space in the Contents value.

  This is explained in section 5.4.3 of ETSI EN 319 142-1. In particular, the value of the messageImprint field within the TimeStampToken shall be a hash of the bytes of the document indicated by the ByteRange. The ByteRange shall cover the entire document, including the Document Time-stamp dictionary but excluding the TimeStampToken itself (the entry with key Contents).

Whichever option you took, you now have a B-T.

• The TSA certificate is added to the DSS store

• Repeat the process above for the OSCP response, again where does the OSCP signature go? or is it a case of building up the signature within the contents value, eg

  1. signers digital sig
  2. signers digital sig + timestamp (signed by TSA)
  3. TSA digital sig + OSCP response (signed by OSCP)

You don't change anything within the PDF with the B-T signature anymore, in particular in the Contents value(s) there. Instead you now append an incremental update to that PDF, see ISO 32000-2 section 7.5.6. In this upgrade you add a DSS structure and fill it with all validation-related material (extra certificates, CRLs, OCSP responses) that are required for a full validation of the signature and time stamp in the B-T PDF.

This gives you a B-LT profile signed PDF.

Add the third sig into contents and decrypt backwards while validating LTV?

I don't know what third sig you mean or what you mean by decrypt backwards.

What you finally do is add a document time stamp to the B-LT, either in the same incremental update as the DSS additions or in yet another one.