Adobe's validation of a PAdES LTV and validation time

[Guest]

When Adobe validates a LTV signature:

* when validating the signer's certifecate, it's validated on the timestamp date. Ok

* but when validating the document timestamp's certificate, it's validated on its own timestamp date !!??

What does it mean?

If I change the date of my system to a date when the timestamp certificate is expired, Adobe says all the LTV signature is OK. !!??

Since the timestamp's certificate was valid when the timestamp was created, then this means that Adobe will consider this LTV eternally valid?

Instead of requiring another document timestamp before previous timestamp expiration.

According to PAdES LTV standard (ETSI TS 102 778-4 V1.1.2):

    4.3 Validation Process

    It is recommended that that validation process be as follows:

    1) The "latest" document Time-stamp should be validated at current time with validation data collected at the current time.

    2) The "inner" document Time-stamp should be validated at previous document Time-stamp time with the validation data present (and time-stamped for the successive     enveloping time-stamps) in the previous DSS.

    3) The signature and the signature Time-stamp should be validated at the latest innermost LTV document Time-stamp time using the validation data stored in the DSS and     time-stamped (by the successive enveloping time-stamps)

Why is Adobe validating the latest document timestamp using its own timestamp date instead of validating it using the current time?

I've detected it in Acrobat Reader DC.

Thanks a lot in advance,

Enric

[Guest]

Even more.

If the signature previous to LTV has a timestamp, that is, it was a PAdES-T, then the validation date that Adobe shows when validating the ES-T timestamp certificate is the current date instead of being the LTV timestamp date.

So, according to the paragraph of PAdES LTV standard (ETSI TS 102 778-4 V1.1.2) that I mentioned in the previous post, I think Adobe's LTV validation is mixing dates:

* it is validating the LTV timestamp certificate in LTV timestamp date instead of validating it in current date.

* it is validating the ES-T timestamp certificate in current date instead of validating it in LTV timestamp date.

Please, Steven.Madwin​ (I'm sorry, but you're the only one person I knew in Adobe related to cryptographic issues), could you make any comments about it ? Is this mix of dates real ? Or am I missing something?

Thanks a lot in advance,

Enric

[Steven_Madwin]

Hi Enric,

Do you have access to the file and if so, is it allowable to send it to me (that is, it doesn't contain any proprietary information)?

Steve

[Steven_Madwin]

Hi Enric,

With regard to your private message, I got the file you posted. Three things:

1. The signatures don't look like they were created with Acrobat or Reader. When it comes to third-party signature creation apps there is not much I can help you with as far as how the signature gets created.
2. In order for Acrobat to recognize the signature as being PADES compliant the /subFilter must be set to /ETSI.CAdES.detached, whereas the /subFilter value in the file you posted is /adbe.pkcs7.detached. That just gets Acrobat to check the PADES  compliance level of the signature. Then, in order for the signature to meet the Basic compliance level the CMS object must conform to to RFC 5035. Additionally, if the signature is going to be -L compliant (Long Term Validation) the revocation information must be embedded in the DSS (this part you've got). Finally, if the signature is going to be -T compliant it must be timestamped (and again, this you've got).
3. A timestamp is always validated in real time, it can't rely upon itself to provide the revocation time-slice. I noticed that you added a document timestamp about 35 minutes after the document signature was created. My guess is you were trying to see if Acrobat would pick that time to do the revocation checking on the signature timestamp, but as you found out it did not. Acrobat does not have the concept of timestamp chaining, and thus each timestamp signature is independent of all other signatures.

Steve

[mwak3121]

Hi Steven,

I have a similar issue reported but bit more.

- Document timestamp is being validated always at time stamp time (same as above) but the SubFilters are proper i.e. /ESTI.CAdES.detached for the user signature and /ETSI.RFC3161 for the document timestamp hence wondering why. As per ETSI PAdeS standard document timestamp must be verified at current time

- The signature timestamp has its revocation embedded (OCSP) and verifying it at document time but it is stilling going online why?

Details

I have analysed the internals of the signed PDF and I see no valid reason for Adobe Acrobat to go online for the Signature Timestamp revocation as its embedded and valid. I have pulled all the embedded OCSP responses (from the DSS) in the signed PDF which are 3 in number; one for TSA cert, one for user's cert and one for Sub CA cert. The same TSA cert is used to create the document timestamp and signature timestamp. The Document Timestamp verifies uses embedded OCSP while the signature timestamp created by the same TSA uses online OCSP which doesn't make sense. All the OCSP Responders have 'NoCheck' extension in it. The 'produced at' time for the embedded OCSP responses for the TSA cert was prior the production of the document timestamp hence the embedded OCSP response is valid at document timestamp time. 'This Update' and 'Next Update' extensions in the OCSP response is also correct.

I have checked against Adobe Reader XI, Adobe DC and Adobe Acrobat and found same behavior there.

I am sending the PDF file privately to you. Hope you can guide me on this..

[Steven_Madwin]

Hi mwak,

Let's start with the ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification. Section 4.3 recommends the validation process, it is not a requirement to be PAdES complaint. As I mentioned above, Acrobat has no notion of timestamp chaining. That is, a new timestamp cannot be used to validate an earlier timestamp. Each timestamp stands unto itself. When it comes to validating a timestamp (also noted above) the timestamp time cannot be used to validate the certificate chain used to create the timestamp signature. Thus, Acrobat (and Reader) must procure revocation information in real-time to validate the certificate chain used to create the timestamp. The timestamp time is used to validate a document signature, but not itself.

Signature validation is really a two part operation. First, the integrity of the document is validated by making sure the signed bits match the current bits listed in the signed byte range (which defines that portion of the document that was signed). There is no time involved in that part of the signature validation. The second part of signature validation is checking the integrity of the signer. There are a lot more bits of minutia that are involved in the signer integrity check than there are in the document integrity check. The first thing that has to be establish is the signing chain must be built. Then the signing chain is checked to see if any of the certificates in the chain have been designated as a trust anchor. Without trust nothing else happens. Once trust is established then a time-slice to use for validation has to be defined. This is where a timestamp comes into play. If the document recipient has chosen to do validation at the current time, then they use the time from their own computer. If they have chosen to validate the document signature at signing time then the timestamp time is used if it is present.

At some point in all of this the certificate used to sign the timestamp token (which contains the timestamp time) has to be validated. This always happens at the current time as the timestamp authority cannot use their own time to validate their certificate chain. There are Acrobat preferences to not throw out the timestamp token if the cert validation cannot be done. This is why when you move the clock ahead to a point past the time those certs have expire the timestamp is not invalidated and tossed out.

There are rules that state that a certificate authority is not required to provide revocation information on an expired certificate (otherwise the certificate revocation lists would grow to an unwieldy size). Because of this Acrobat cannot trust that just because an expired cert is not on the CRL that it was not revoked at signing time. With document signatures, once the signing cert has expired, if the revocation information that was used as signing time was not embedded in the PDF, then the signature changes to an Unknown status. With a timestamp signature we don't do that, when they expire we just ignore doing revocation checking and continue to use the timestamp's time-slice to validate the document signature.

Steve

[mwak3121]

I appreciate for the above details...

Any benefit Adobe achieves by not following the recommendations by ETSI?

One confusion... if in Adobe Acrobat all timestamps are verified at current time then why at my end the document timestamps in Adobe Acrobat are verified using the time the document timestamp was created at. Shouldn't it be verified at current time then?  I even tried by setting the option to verify at 'current time'

[Steven_Madwin]

Hi mwak,

Here is where we are getting into the minutia of digital signatures. It all starts with RFC 5652 - Cryptographic Message Syntax (CMS), which itself was born from the old RSA PKCS#7 specification. This spec defines how signed data is formatted. Within Section 5.3 is defined the layout of the Signer Info. The last part of the Signer Info is a section for unsigned attributes.

With a regular document signature (were the signature is created by an end-user) the document's signed attributes are hashed (aka digested) and that hash (or digest if you prefer) are sent to the timestamp server where they themselves are signed. That signature (the timestamp signature) is then written into the unsigned attributes section of the Signer Info. Because the timestamp token is written into the unsigned attributes it is processed separately from the document signature, and that's why the signature validation of the timestamp is done in real time.

A document timestamp signature is created in a different manner. In this case the timestamp token is part of the document signature. Ultimately, a document timestamp signature is much the same as a user created document signature, but instead of the signed bytes being signed with a user's end-entity certificate, they are signed by a trusted 3rd party timestamp server. In this case (and this is the big difference) the timestamp token returned by the timestamp server is written into a signed portion of the CMS package. An update was made to the PDF specification (ISO-32000) to accommodate a document timestamp signature that tells the validating app (in this case Acrobat, but it could be any PDF viewer that wants to do signature validation) to get the time-slice from the timestamp token in the signed attributes of the CMS package.

Finally, when ETSI wrote the PAdES Technical Specification they modeled it on what Acrobat already did. They knew we didn't yet do timestamp chaining, and thus made that part of the spec recommended as opposed to required. The concept was that someday we may add timestamp chaining, but with the improvements with Acrobat's Long Term Validation signature processing it became less of a need and truthfully I doubt it will ever be implemented as there is no real ask from customers. Our engineering resources (and not just ours, but every software/hardware company in the world) are limited by time and manpower and there are other request from customers that are more pressing.

Steve

[venkataswamyp77110602]

Hi Steven.Madwin,

I am also facing the same type of issue.

The below are the steps i followed to apply digital signatures.

1. Created a sample Pdf file with PDF/A conformance using iText7 Api
2. Created a PKI(with Root CA, Issuing CA and Online Responder)
3. Issued Certificate 1.
4. Applied Digital Signature using certificate 1 in offline mode using iText7 Api (i.e. no verification information added means that no DSS section)
5. Issued Certificate 2
6. Applied Digital Signature using certificate 2 in online mode using iText7 Api. While applying this signature added verification information(OCSP responses) of the certificates used in both digital signatures.

I have created two separate PKI environments(e.g. PKI1 and PKI 2) and generated 2 digitally signed pdf files (e.g. pki1.pdf and pki2.pdf) by following the above mentioned steps.

When i opened the pdf files in Adobe Acrobat Reader DC 2018.011.20055 then the Acrobat Reader is showing

1. Signature is LTV enabled for both signatures in pki1.pdf
2. Signature is not LTV enabled for both signatures in the pki2.pdf (this behavior is appearing from last couple of months means that previously, when i generated the same type of digitally signed pdf using pki2, the Acrobat Reader was showing Signature is LTV enabled)

Please advice me about the reason why Adobe Acrobat Reader is showing 'Signature is not LTV enabled' for the pki2.pdf. I am happy to provide the two pdf files to you.

Thanks & Regards

Venkataswamy Pavali

[Steven_Madwin]

Hi Venkataswamy,

For the signatures created using the digital IDs from the PKI2 environment, try the following:

• Open the Signature Panel
• Right-mouse click on the signature, and then select Show Signature Properties from the pop-up menu
• Click the Show Signer's Certificate button on the Signature Properties dialog
• Select the Revocation tab on the Certificate Viewer dialog
• If it doesn't mention that the revocation information (be it CRL or OCSP) "is embedded in the document" then the signature will not be LTV enabled.
• Let me know if it is embedded, but the signature is not LTV enabled, and then we'll go from there.

Steve