问ETSI.CAdES.detached与adbe.pkcs7.分离PDF签名的区别

EN

在一篇评论中，您澄清了您的“目标是B类型签名”；因此，这个答案假设了这个PAdES配置文件。在这段评论中，你还暗示你想要与Adobe的“支持LTV”相比较的“长期能力”。因此，在这里，我们还探讨了这个术语的含义和不含义。

格式

对于我到目前为止所理解的

，主要的区别是/SubFilter值、DSS结构、ESS属性和文档时间戳。所有4项更改是否都必须符合标准？

实际上，对于实际的ETSI.CAdES.detached，be签名(相对于ISO 32000-1 adbe.pkcs7.detated签名)，SubFilter值必须是，必须添加DSS结构，并且必须存在ESS签名证书。此外，签名后需要时间戳，但它不一定是文档时间戳，签名容器中的签名时间戳也足够了。

不过，还有更多的不同之处。例如，对于PAdES签名，嵌入的SignedData对象必须与CAdES中描述的对象相同。根据您的SignedData对象的内容，这可能会产生不同的效果，例如here。认真对待所有的规范，以防止令人讨厌的惊喜。

，ESS属性是如何在SignedData结构中构造的，其中还有其他的变化吗？

ESS签名证书属性在RFC 2634和RFC 5035中指定，并在ETSI EN 319 122-1中用于CAdES和PAdES中。SignedData、SignerInfo和属性结构在RFC 5652和其中引用的其他文档中定义。

请认真对待这些RFCs是如何被CAdES和PAdES描述的！例如，RFCs允许在相同的签名中同时包含ESScertID和ESScertIDv2，而在CAdES/PAdES中，只允许和需要这些属性中的一个。

长期能力

最终的PDF文档是否具有与adbe.pkcs7分离的长期功能？

在一篇评论中，您澄清了让Acrobat为您的adbe.pkcs7.detached签名显示“支持LTV”的功能对您来说是“长期功能”。考虑到这一点:是的，Acrobat还为PAdES that签名显示了“LTV支持”，在AATL或EUTL上有信任锚。

在ETSI文档中提到，必须在文档过期之前重新应用文档时间戳和DSS以保持签名的有效性，为什么在adbe.pkcs7分离的文档中没有出现这种情况，如何避免这种情况呢？

请注意，ETSI文档采用与Acrobat不同的验证策略：

首先，允许长期验证对签名意味着什么？这意味着签名容器(在集成PDF签名的情况下，整个PDF)带来了验证签名所需的所有信息。但是，哪些信息是验证所必需的，取决于应用的验证策略！

Acrobat应用的验证策略非常宽松。特别是，它基本上信任问题中所有令牌(签名、撤销数据、.)中的所有时间指定。此外，它不要求撤销数据严格地比签名年轻，但允许它们稍微老一点。

另一方面，欧洲合格电子签名的适当验证政策则以ETSI EN 319 102-1为基础，而ETSI TS 119 172-4则更为严格。特别是，它需要对所涉及的令牌中的多个时间指定进行证明，并且只接受比其所使用的签名更年轻的撤销数据。

ETSI文档中提到有必要在文件到期前重新应用文档时间戳和DSS以保持签名的有效性，这隐含地假定了欧洲合格电子签名的验证政策，在这些政策中时间戳是重要的和必需的。

在adbe.pkcs7.脱离文档中没有发生这种情况，因为您使用Acrobat及其信任验证策略验证该文档。

顺便说一句，这特别意味着嵌入在启用LTV的ISO 32000-1 adbe.pkcs7中的撤销信息不能用于适当的欧洲合格电子签名验证:在您的示例中，吊销信息比签名更早(至少稍早)，因此无法用于验证。

目标

现在的目标是将子过滤器改为ETSI.CAdES.detached，以遵守一些规定，其中提到ETSI EN 319 142-1为所需格式。

那你应该再检查一下规定。仅要求ETSI EN 319 142-1作为格式尚不明确，至少应参考其中规定的一个或多个基准概况。