后续的 PDF 签名会使之前的签名失效

Question

我在将多个数字签名应用于使用更新版本的 Go 包 github.com/digitorus/pdfsign 生成的 PDF 文件时遇到问题。

在 Adobe Acrobat 中查看文档时，添加后续签名后，第一个签名将失效。

1. 第一个签名已应用并验证成功。
2. 添加后续签名后，第一个签名将失效（在 Acrobat 中显示为“无效”）。
3. 有趣的是，每个签名在单独检查时都会单独验证。

只有最后一个签名才能正确验证：

签名

在 Acrobat 中使用“查看签名版本”检查第一个签名时，该签名也可以正确验证：

查看签名版本

使用 Adobe Acrobat Preflight 检查原始或签名文档是否存在 PDF 语法问题，未检测到任何问题。

飞行前

基于这个类似的问题，似乎在应用第一个签名时，文档可能在保存时出现了一个小错误。因此，Adobe Acrobat 似乎认为 PDF 中的每个签名都已损坏，但完整（最新）文档的签名除外。

上面突出显示的问题是由分段外部参照表引起的，但这里的情况并非如此，因为我没有分段外部参照表。另外，当从头开始重新创建整个外部参照表时，我遇到了同样的问题。

我怀疑增量更新可能还有其他问题。

附加到 PDF 文档的增量更新如下所示：

10 0 obj
<< /Type /Annot /Subtype /Widget /Rect [0 0 0 0] /P 5 0 R /F 132 /FT /Sig /T (Signature10) /Ff 0 /V 12 0 R >>
endobj
11 0 obj
<< /Type /Catalog /Pages 2 0 R /AcroForm << /Fields [7 0 R 10 0 R] /NeedAppearances false /SigFlags 3 /Perms << /UR 12 0 R >> >> >>
endobj
12 0 obj
<< /Type /Sig /Filter /Adobe.PPKLite /SubFilter /adbe.pkcs7.detached /ByteRange [0 5000 7870 414]                   /Contents<308204e306092a864886f70d010702a08204d4308204d0020101310d300b0609608648016503040203300b06092a864886f70d010701a08202903082028c308201f5a003020102021411ea8e89c304b42bad08db8136af460103580f5d300d06092a864886f70d01010b05003057310b3009060355040613024e4c3113301106035504080c0a536f6d652d537461746531123010060355040a0c0944696769746f727573311f301d06035504030c165061756c2076616e2042726f7577657273686176656e3020170d3234313131333039353131315a180f32313234313032303039353131315a3057310b3009060355040613024e4c3113301106035504080c0a536f6d652d537461746531123010060355040a0c0944696769746f727573311f301d06035504030c165061756c2076616e2042726f7577657273686176656e30819f300d06092a864886f70d010101050003818d00308189028181009abbeb66251967f9d298528cb105e0e6c9584d08e3ee7b9e9dccedeca18f56e180f2734eaa21a4b5ffb27a9e61dabf3b8cfbd58d55e32558ce4cac7d1cc85a144087287295ef6890865c387d76bc881d440de1aec0ffa94e9456973bab43f60cc6f7a634955c18c7d3138d97e4182a87a0ef91d7514c079ea900c10fafb954fb0203010001a3533051301d0603551d0e0416041444e2ce2d9b4cb44c2249d05d60d19d0e7dc48f7d301f0603551d2304183016801444e2ce2d9b4cb44c2249d05d60d19d0e7dc48f7d300f0603551d130101ff040530030101ff300d06092a864886f70d01010b0500038181003819e0f84cc3db103a785fd6e5687e3ed844d4ca49d50bde8d9043c823a2a65585508989017dfd65f4e8fd875fcf6c51e09c3884e1749122f10cae161ad0acee6441d1ddb8603270a498f428de7eba1de25a4e68ad8ef91527a7b1f2d937b60856e50ded0fb6bfcec58d6b25d30dc23dca6307a120239407b0d9b5ddb9102db43182021930820215020101306f3057310b3009060355040613024e4c3113301106035504080c0a536f6d652d537461746531123010060355040a0c0944696769746f727573311f301d06035504030c165061756c2076616e2042726f7577657273686176656e021411ea8e89c304b42bad08db8136af460103580f5d300b0609608648016503040203a0820100300f06092a864886f72f01010831023000301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3234313131333131313531305a304f06092a864886f70d01090431420440b35bead7e94a1ac181444e83d78d858feaaad7dee19e84c5b72a5ae5cb69b67fd686fc90d8e2f237200bf4aaa33e0218f669ea924a506dec438d8845896932cf3064060b2a864886f70d010910022f315530533051304f300b0609608648016503040203044048e7b14c70a3beb47b5b8af714af447e03db88f72eba5307afa4c6862537d40fae77371b9a31baeda1a5dcfbe1d7a6a85aa98f64f26a47fdac1de06c06d8eed1300b06092a864886f70d01010d04818074135f1a3f5d6120baa154ccb01f4331df19f9b29cc444ab586091774caa267075642d28f8e8275167fa516d87cc091eecd16dcb7d22992898d774bc8a27cc17c4bef224c1dc60178aeab1f4601b4cb308b0042685d7e0744fd9bde17a3ba0052e519a2a79d3e456d4aca10554b165a910da3b62ef94939b1a6ed72c3d0165820000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000> /TransformMethod /FieldMDP /TransformParams << /Type /TransformParams /Fields [<< /Type /SigFieldLock /Action /All >>] /V /1.2 >> /Name (Jane 2 Doe) /Location (Anywhere) /Reason (Approval Signature 2) /ContactInfo (None) /M (D:20241113121510+01'00') >>
endobj
xref
10 3
0000004592 00000 n 
0000004718 00000 n 
0000004866 00000 n 
trailer
<<
    /Root 11 0 R
    /Prev 4441
    /Size 13
>>
startxref
8131
%%EOF

文件

• 源文件small.pdf
• 签名文件 SignPDFWithTwoApproval_2_556137430.pdf

Answer 1

签名字段值有一些奇怪的条目

TransformMethod

:

/TransformMethod /FieldMDP 
/TransformParams << 
    /Type /TransformParams 
    /Fields [
        << 
            /Type /SigFieldLock 
            /Action /All 
        >>
    ] 
    /V /1.2 
>>

/Fields

值无效。它看起来像是

TransformParams

变换方法的

FieldMDP

和签名字段的

Lock

条目的混合。

文档

UR

字典中还有一个

Perms

键引用最后一个签名（这也由两个签名更新/更改）。但是：PDF 规范中定义的权限字典没有

UR

键。

也许这些问题会让验证引擎失败。