0

I've got a doubt about how to create the VRI entry for a timestamp that's inside a PAdES signature.

Let's suppose there is a pdf document with a Signature and this signature has an embed timestamp.

Example:

\Sig
[...]
\Contents <1234567890ABCDEF[...]>
[...]
Type \DSS
\VRI <<
     \Hash1 object1
     \Hash2 object2
>>
[...]

Hash1 is easy to calculate: It's the whole signature hash, including the timestamp ( 1234567890ABCDEF[...] )

But Hash2... What should I use to calculate it? In the ETSI document, it's written like this (PAdES LTV Profile - Part 4 - V1.1.2 page 12):

For a Time-stamp's signature it is the bytes of the Time-stamp itself since the Time-stamp token is a signed data object

But I must say that didn't help a lot. Is it the timeStampToken? Only the content? What is "The time-stamp itself"?

Does anyone know any document that clarifies this? Reference implementation

Diego Azevedo
  • 73
  • 9

1 Answers1

1

The definition you quote

For a Time-stamp's signature it is the bytes of the Time-stamp itself since the Time-stamp token is a signed data object

is from the ETSI TS which first defined pades LTV structures.

This TS meanwhile has been superseded by the ETSI EN 319 142-1 where the definition was reformulated as:

For document signatures or document time-stamp signatures the bytes that are hashed shall be those of the complete hexadecimal string in the entry with the key Contents of the associated Signature Dictionary containing the signature's DER-encoded binary data object (e.g. PKCS#7, CMS or CAdES objects).

Thus, for document time stamps simply proceed just like for regular signatures.

By the way, the same norm specifies:

The VRI dictionary should not be used. The inclusion of VRI dictionary entries is optional. All validation material referenced in VRI entries is also referenced in DSS entries

So you might not need these entries at all.

I just realised that you supposed

there is a pdf document with a Signature and this signature has an embed timestamp.

An embedded timestamp admittedly is not subject to the quote above. But indeed the time stamp token is a ContentInfo object wrapping a SignedData object, just like a regular CMS signature container. Thus, the time stamp token is the object to hash.

mkl
  • 90,588
  • 15
  • 125
  • 265
  • Thank you, @mkl! I didn't know this new document, and the reading clarified other doubts I had. I also think it should (logically) be the token, but I must say I still have my doubts when reading that quote from the previous document. It uses both terms "time-stamp itself" and "time-stamp token" and does not make it clear it's the same thing. Are there other documents ETSI made that override/clarify ETSI TS documents? – Diego Azevedo Oct 10 '16 at 12:56
  • Also, I live in Brazil, and whe extended ETSI PAdES signatures to our purposes (We use policies, and some kind of Policy Revocation List), and here the VRI dictionaries are mandatory. So, while I will ask Brazilian committee to clarify this themselves, I'd like it to be the same ETSI uses. – Diego Azevedo Oct 10 '16 at 13:05
  • The "time stamp token" is the "time stamp itself" in contrast to the time stamp response or time stamp attribute which contain the token and more. I'm not aware of other clarifications on that matter but there may well be as there have been multiple interim versions of the PAdES specifications. Simply search for PAdES on the ETSI web site and allow older document versions. – mkl Oct 10 '16 at 13:23
  • @DiegoAzevedo By the way... *Brazil, and whe extended ETSI PAdES signatures to our purposes* - are the specifications for this customized PAdES use available in English, too? If yes, can you point towards a link to them? – mkl Oct 10 '16 at 13:26
  • ! I'll search ETSI site and re-check. Unfortunately, those specifications are avaiable only in portuguese. But you can download the List of Approved Policies (LPA) here: http://politicas.icpbrasil.gov.br/LPA_PAdES.der This is an ANS1 file with links to our valid PAdES policies. There was little change from the ETSI docs. We only restricted the signer chain, made the VRI mandatory on 2 of our policies, and added the policy, policy signature and LPA to the DSS/VRI on one of them. – Diego Azevedo Oct 10 '16 at 14:18