Adobe Reader/Acrobat中的时间戳验证失败:文档已更改或损坏 [英] Timestamp Validation in Adobe Reader / Acrobat fails: Document was changed or damaged

问题描述

我目前正在开发一个时间戳服务，以生成符合PAdES-4的时间戳.从Swisscom/Swisssign/QuoVadis服务器收到的时间戳可以很好地工作.但是，只要我使用从自己的时间戳记权威机构或Signtrust收到的时间戳记，Adobe Reader(版本11.0.06)都会以德语注释拒绝我的时间戳记:"Dokument wurde nach dem Unterzeichnenverändertoderbeschädigt"，这意味着文档已更改或在创建签名后损坏".将所需的证书添加到信任列表(以便tsa签名者证书成功验证)不会对此行为产生影响.

由于从上述TSA收到的时间戳可以正确验证，因此我认为我的基本摘要计算很好.

由于我的基于外部(非PAdES)的CMS时间戳可以使用替代签名应用程序正确验证，因此我认为摘要的编码以及时间戳结构都很好.

使用我自己的TSA，我使用与Swisssign相同的摘要算法和结构，但是Adobe Reader不会接受它.由于没有Adobe Reader提供的更多错误详细信息，我有点迷失了.

有人知道吗，文档中的时间戳出了什么问题: https ://dl.dropboxusercontent.com/u/40847151/Timestamping/TS%20-%20Swisssign.pdf

任何提示都非常感谢！

此致

托马斯

解决方案

TS-selfsigned.pdf

您的TSA证书不符合RFC 3161.

我不确定这是否是Adobe软件拒绝您的时间戳的原因，但至少是每个每个RFC 3161时间戳验证软件都应拒绝它的原因.

RFC 3161 要求

2.3. TSA的标识

TSA必须在每个时间戳记消息上签名并保留一个密钥 专为此目的.一个TSA可能有不同的私钥， 例如，为了适应不同的政策，不同的算法， 不同的私钥大小或增加性能.这 相应的证书必须只包含一个实例 [RFC2459]节中定义的扩展密钥用法字段扩展 4.2.1.13，KeyPurposeID的值为:

id-kp-timeStamping.  This extension MUST be critical.

以下对象标识符标识具有以下内容的KeyPurposeID: 值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)}

如果您的证书的扩展密钥用法扩展名不是关键"，则为不重要，相反，样本SwissSign时间戳的TSA证书已将扩展密钥用法扩展名标记为关键".

据说，众所周知，BNetzA不想在其颁发的证书中添加其他关键扩展.如果您希望您的时间戳服务最终获得德国签名法(SigG)的认可，请准备好一些乐趣...

TS-EKUcritical.pdf

修复扩展密钥用法扩展后，Adobe仍然拒绝OP的时间戳.因此，对结构进行更深入的研究:

第一个有趣的字段是TSTInfo结构中的serialNumber:

133 02    4:                 INTEGER -171182259

是负面的.尽管该标准实际上并没有禁止它(仅要求它是唯一的)，但某些软件可能要求它为非负数，就像证书的序列号一样.

下一个是SignerInfo结构中的contentType属性:

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)
            :                 }
            :               }

Swisssign时间戳记将内容类型声明为TSTInfo结构:

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))
            :                 }
            :               }

此外，您的CMS结构包含SigningCertificateV2属性，但不包含SigningCertificate属性. Swisssign使用SigningCertificate属性.

RFC 3161 需要SigningCertificate属性:

必须将TSA证书作为signerInfo属性包含在 SigningCertificate属性.

RFC 5816 针对V2表单进行了更新，但ETSI TS 102 778-4仅考虑了RFC 3161

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:

The certificate identifier (ESSCertID) of the TSA certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute.

RFC 5816 updates this for V2 forms but ETSI TS 102 778-4 only considers RFC 3161.

这篇关于Adobe Reader/Acrobat中的时间戳验证失败:文档已更改或损坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！