为什么这两个 itext 7 签名和验证文档之一对 Adobe DC 阅读器无效？答案

【问题标题】：Why is one of these two itext 7 signed and validated document is not valid with Adobe DC reader?为什么这两个 itext 7 签名和验证文档之一对 Adobe DC 阅读器无效？
【发布时间】：2017-07-17 14:33:15
【问题描述】：

我有两个经过认证的 pdf 文档（使用基于 Itext 7 的相同机制签名和验证），当我使用 adobe reader DC 检查其有效性时，只有一个带有绿色标记。

好的： https://1drv.ms/b/s!AkF6t4TavwMvgxWaidlUqvPvHH1r

坏的： https://1drv.ms/b/s!AkF6t4TavwMvgxQCMdGY61S1EvUh

问候

大卫·L

【问题讨论】：

具有相同的机制 - 这个机制是如何确切地设计的？例如。你是作为增量更新签名的吗？
嗨，看看这篇解释方法的旧帖子：
stackoverflow.com/questions/39151230/…
恼人的是，这两个文档的签名在 Itext 7 中通过了验证，但在 adobe dc reader 中却没有通过……Adobe 告诉你坏的已经被篡改了
我用福昕检查了这两个文件，两个证明签名都被认为是有效的......adobe reader DC是什么？

标签： pdf itext adobe signature itext7

【解决方案1】：

这不是 Adobe 错误，而是一项功能。（还有一个 iText 错误）

当 Adobe 执行加密验证时，它还会执行其他检查以查看签名是否受到攻击。它分析了几个嫌疑人，如果该分析结果是否定的，Adobe 将向您显示一条错误消息。这是 Adobe 误报了分析和有效性。但是，对于这些隐藏的要求，有一种变通方法。

首先，在非附加模式下使用 iText 来修改文档：

不幸的是，在特定情况下，iText 7 在非附加模式下使用时会引入规范不允许的更改。问题是 iText 引入了小节。这是规范允许您做的事情，但在第一个修订版中明确不允许这样做：

第 7.5.4 节交叉引用表 [...] 对于从未增量更新的文件，交叉引用部分应仅包含一个子部分，其对象编号从 0 开始。[...]

您将在下面找到 iText 在非附加模式下使用后的第一个修订版的外部参照，每个彩色矩形都是一个新的小节。为了符合要求，应该只有一个矩形。

这将在计划于 7 月底发布的 7.0.4 版本中得到修复。

【讨论】：

这不是 Adobe 错误 - 好吧，Adobe 同时说“自应用此签名以来对该文档所做的某些更改是不允许的由文件作者。”和“自从应用此签名以来，此文档没有任何更改。”有人可能会说这不是错误，而是 garbage-in,garbage-out 的情况，但 Adobe 仍应考虑在其签名验证输出中防止此类矛盾。
确实如此。我上周向 Adobe 报告了这个令人困惑的报告，我们将看看他们是否会对此采取任何措施。
Michaël，您收到 Adobe 的回复了吗？
我们与一些 Adobe 开发人员进行了讨论。他们证实了我上面写的。这意味着 Adobe Reader/Acrobat 会进行额外的检查，并且会误报签名的有效性。我要求提供有关此修改分析的一些公开文档，以便我们可以包括这些检查（在有意义的地方）。但我没有得到对该请求的答复。我们最近再次敦促他们提供更多信息，但同样没有回应。附带说明：上述问题已得到修复，拆分 XREF 表不应再成为 Adobe 中消息的原因。但这就是我们现在所能做的。
好的，谢谢。我问是因为有些人仍然使用早期的 iText 7.0.x 版本并遇到这个问题，cf。 this question.

【解决方案2】：

由于多个其他工具验证这两个文档没有任何问题......我们可能认为这是一个 adobe 阅读器错误。

尤其是 Adobe Acrobat 本身已被撕裂：

【讨论】：