Adobe Reader/Acrobat中的时间戳验证失败:文档已更改或损坏

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.pdfYou cann find the working Swisssign test file here: https://dl.dropboxusercontent.com/u/40847151/Timestamping/TS%20-%20Swisssign.pdfAny hint is highly appreciated!Regards,Thomas 解决方案 TS - selfsigned.pdfYour 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.pdfAfter 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 -171182259It 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中的时间戳验证失败:文档已更改或损坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！