Timestamp Validation in Adobe Reader / Acrobat fai

I'm currently working on a timestamp service producing PAdES-4-compliant timestamps. This is working fine with timestamps received from the Swisscom / Swisssign / QuoVadis servers. But whenever I use a timestamp received from my own timestamping authority or Signtrust, Adobe Reader (Version 11.0.06) keeps rejecting my timestamp with the German comment: "Dokument wurde nach dem Unterzeichnen verändert oder beschädigt", which means 'The document was changed or damaged after signature creation'. Adding the required certificates to the trust list (so that the tsa signer certificate validates successfully) has no impact on this behavior.

Since the timestamps received from the TSAs mentioned above validate correctly, I assume that my basic digest calculation is just fine.

Since my external (non-PAdES) CMS-based timestamps validate correctly with alternative signature applications, I assume the digest's encoding as well as the timestamp structure are just fine.

With my own TSA, I use the same digest algorithms and structures as Swisssign, yet Adobe Reader just won't accept it. Since there is no further error detail given by Adobe Reader, I'm kind of lost.

Has anyone got an idea, what is wrong with the timestamp in the document found under: https://dl.dropboxusercontent.com/u/40847151/Timestamping/TS%20-%20selfsigned.pdf

You cann find the working Swisssign test file here: https://dl.dropboxusercontent.com/u/40847151/Timestamping/TS%20-%20Swisssign.pdf

Any hint is highly appreciated!

Regards,

Thomas

TS - selfsigned.pdf

Your TSA certificate does not conform to RFC 3161.

I'm not sure whether this is the reason why Adobe software rejects your time stamp but it at least is a reason why each and every RFC 3161 time stamp verifying software should reject it.

RFC 3161 requires

2.3. Identification of the TSA

The TSA MUST sign each time-stamp message with a key reserved specifically for that purpose. A TSA MAY have distinct private keys, e.g., to accommodate different policies, different algorithms, different private key sizes or to increase the performance. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value:
id-kp-timeStamping.  This extension MUST be critical.
The following object identifier identifies the KeyPurposeID having value id-kp-timeStamping.
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
               identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7)
               kp (3) timestamping (8)}

In case of your certificate the extended key usage extension is not critical, the TSA certificate of the sample SwissSign time stamp in contrast has marked the extended key usage extension as critical.

That been said, the BNetzA is known not to want additional critical extensions in the certificates they issue. If you want your time stamping service eventually to be accredited according to the German Signature Act (SigG), get ready for some fun...

TS - EKU critical.pdf

After fixing the extended key usage extension, Adobe is still rejecting the OP's time stamp. Thus, a deeper look into the structures:

The first interesting field is the serialNumber in the TSTInfo structure:

133 02    4:                 INTEGER -171182259

It is negative. While not actually forbidden by the standard (which only requires it to be unique), some software may require it to be non-negative, just like the serial numbers of certificates.

The next one is the contentType attribute in the SignerInfo structure:

1290 06    9:               OBJECT IDENTIFIER
            :                 contentType (1 2 840 113549 1 9 3)
            :                 (PKCS #9 (1 2 840 113549 1 9))
1301 31   11:               SET {
1303 06    9:                 OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
            :                   (PKCS #7)
            :                 }
            :               }

The Swisssign time stamp declares the content type as a TSTInfo structure:

3540 06    9:               OBJECT IDENTIFIER
            :                 contentType (1 2 840 113549 1 9 3)
            :                 (PKCS #9 (1 2 840 113549 1 9))
3551 31   13:               SET {
3553 06   11:                 OBJECT IDENTIFIER
            :                   id-ct-TSTInfo (1 2 840 113549 1 9 16 1 4)
            :                   (S/MIME Content Types (1 2 840 113549 1 9 16 1))
            :                 }
            :               }

Furthermore your CMS structure contains a SigningCertificateV2 attribute but no SigningCertificate attribute. Swisssign uses a SigningCertificate attribute.

RFC 3161 requires a SigningCertificate attribute: