"detached" PDF 数字签名
"detached" digital signatures in PDF
我想实现 "parallel" PDF 签名过程，以便用户可以同时对文档进行数字签名，而不是 "one by one"。为实现这一点，我决定为所有用户创建初始文档的单独副本并获得签名。最终，所有签名都应该连接成一个 PDF。
假设 PDF 在签名过程中没有变化，签名字段创建除外（所有 acroForms、signatureContainers、视觉签名等都是之前创建的并且对所有类似）。
.. 在进一步调查期间，我阅读了 this 文章并了解到，每个先前的数字签名（甚至是分离的）都包含在下一个签名的 SignedContent 中。所以没有办法将数字签名与内容完全分开。这会导致一个问题，在上一个签名完成之前，无法计算下一个签名。
请告知是否有解决此问题的方法？或者签名 "one by one" 是唯一的解决方案？
P.S。我正在使用 Apache PDFBox 处理 PDF。
Please tell if there is any option to get around this?
如果您希望您的签名可以互操作，那是没有办法的。
I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature
这个答案仍然代表了现在的情况。如果有的话，它已被更新的规范确认，例如该答案中引用的 PAdES 规范仅仅是 'technical specifications' (ETSI TS 102 778)，现在有实际规范 (ETSI EN 319 142)，它也需要 pdf 签名来签署其修订版中的所有内容，除了它自己的签名容器。 ISO 32000-2 也已发布，仍然具有对其可互操作签名的要求，并且还包括 PAdES 规范的缩短副本。
你在这里强调"even detached"。上下文中的"detached"仅指嵌入在PDF中的CMS容器的结构；它特别是 不是 指的是签名更多 与 PDF 或类似的东西 分开。
如果你不需要互操作，虽然有一些选项，这里有两个仍然非常接近可互操作的签名：
您可以忽略 pdf 签名必须签署其修订版中除其自己的签名容器之外的所有内容的要求。
例如，您可以在文档的单个新修订版中准备多个签名字段和字典，并设置每个签名的签名字节范围以排除 所有 这些签名的占位符。
您可以忽略CMS签名容器中只有一个SignerInfo的要求，将不同签名方的SignerInfo放入一个签名容器中的一个签名域中。
常用 PDF 签名验证器 会，
如果是按照前一个选项中描述的方式创建的签名，则至少其中大部分未被积极验证，
要么是因为他们的代码仅针对两个范围的带符号字节（即单个间隙）进行编程，因此仅使用前两个范围导致错误的文档哈希；
或者因为他们明确要求签名覆盖其整个修订版减去正在验证的签名字段的签名容器的单个占位符；自从 Karsten Meyer zu Selhausen 在波鸿鲁尔大学发表 "Security of PDF Signatures" 硕士论文以来，这类验证者的数量肯定有所增加，参见 this question.
如果签名是按照后一个选项中的描述创建的，似乎 积极验证，至少其中很多，直到您查看验证结果详细了解并意识到他们只验证了 SignerInfos 之一而忽略了其他信息。
例如，在两个 SignerInfos 的情况下，Adobe Reader 验证第二个（我假设它总是验证 最后一个 一个）并且 eSig DSS 验证第一个，并且它们目前都没有在验证结果中表明可能存在另一个 SignerInfo。
例如，瑞典一家大型安全公司在其软件中实现了第二个选项；在其自制格式 PDF/CAdES-A 中，它将 CAdES-A 容器作为 CMS 容器插入到 PDF 中，并允许其中包含多个 SignerInfo。因此，很明显，它自己的软件将识别并验证所有 SignerInfo。尽管如此，这是一个家庭酿造解决方案，不可互操作。
您可以使用支持签名工作流程的现有软件 - 例如我们在 https://www.esignanywhere.net 提供 - 该软件允许定义签名工作流程（通过 API 或网络用户界面）。输入可以是 PDF 文档，签名字段作为宏表单字段，或 PDF 中的文本占位符。 eSignAnyWhere 中定义的元信息允许将其分配给特定的签名者。工作流功能允许定义顺序、并行或混合顺序+并行、签名工作流。
我想实现 "parallel" PDF 签名过程，以便用户可以同时对文档进行数字签名，而不是 "one by one"。为实现这一点，我决定为所有用户创建初始文档的单独副本并获得签名。最终，所有签名都应该连接成一个 PDF。
假设 PDF 在签名过程中没有变化，签名字段创建除外（所有 acroForms、signatureContainers、视觉签名等都是之前创建的并且对所有类似）。
.. 在进一步调查期间，我阅读了 this 文章并了解到，每个先前的数字签名（甚至是分离的）都包含在下一个签名的 SignedContent 中。所以没有办法将数字签名与内容完全分开。这会导致一个问题，在上一个签名完成之前，无法计算下一个签名。
请告知是否有解决此问题的方法？或者签名 "one by one" 是唯一的解决方案？
P.S。我正在使用 Apache PDFBox 处理 PDF。
Please tell if there is any option to get around this?
如果您希望您的签名可以互操作，那是没有办法的。
I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature
这个答案仍然代表了现在的情况。如果有的话，它已被更新的规范确认，例如该答案中引用的 PAdES 规范仅仅是 'technical specifications' (ETSI TS 102 778)，现在有实际规范 (ETSI EN 319 142)，它也需要 pdf 签名来签署其修订版中的所有内容，除了它自己的签名容器。 ISO 32000-2 也已发布，仍然具有对其可互操作签名的要求，并且还包括 PAdES 规范的缩短副本。
你在这里强调"even detached"。上下文中的"detached"仅指嵌入在PDF中的CMS容器的结构；它特别是 不是 指的是签名更多 与 PDF 或类似的东西 分开。
如果你不需要互操作，虽然有一些选项，这里有两个仍然非常接近可互操作的签名：
您可以忽略 pdf 签名必须签署其修订版中除其自己的签名容器之外的所有内容的要求。
例如，您可以在文档的单个新修订版中准备多个签名字段和字典，并设置每个签名的签名字节范围以排除 所有 这些签名的占位符。
您可以忽略CMS签名容器中只有一个SignerInfo的要求，将不同签名方的SignerInfo放入一个签名容器中的一个签名域中。
常用 PDF 签名验证器 会，
如果是按照前一个选项中描述的方式创建的签名，则至少其中大部分未被积极验证，
要么是因为他们的代码仅针对两个范围的带符号字节（即单个间隙）进行编程，因此仅使用前两个范围导致错误的文档哈希；
或者因为他们明确要求签名覆盖其整个修订版减去正在验证的签名字段的签名容器的单个占位符；自从 Karsten Meyer zu Selhausen 在波鸿鲁尔大学发表 "Security of PDF Signatures" 硕士论文以来，这类验证者的数量肯定有所增加，参见 this question.
如果签名是按照后一个选项中的描述创建的，似乎 积极验证，至少其中很多，直到您查看验证结果详细了解并意识到他们只验证了 SignerInfos 之一而忽略了其他信息。
例如，在两个 SignerInfos 的情况下，Adobe Reader 验证第二个（我假设它总是验证 最后一个 一个）并且 eSig DSS 验证第一个，并且它们目前都没有在验证结果中表明可能存在另一个 SignerInfo。
例如，瑞典一家大型安全公司在其软件中实现了第二个选项；在其自制格式 PDF/CAdES-A 中，它将 CAdES-A 容器作为 CMS 容器插入到 PDF 中，并允许其中包含多个 SignerInfo。因此，很明显，它自己的软件将识别并验证所有 SignerInfo。尽管如此，这是一个家庭酿造解决方案，不可互操作。
您可以使用支持签名工作流程的现有软件 - 例如我们在 https://www.esignanywhere.net 提供 - 该软件允许定义签名工作流程（通过 API 或网络用户界面）。输入可以是 PDF 文档，签名字段作为宏表单字段，或 PDF 中的文本占位符。 eSignAnyWhere 中定义的元信息允许将其分配给特定的签名者。工作流功能允许定义顺序、并行或混合顺序+并行、签名工作流。