有！ 我正在使用pdfbox 1.8.11来做pdf签名，我可以创建一个支持LTV的签名，其中嵌入了DSS字典。现在问题是当有多个签名时进行证书验证。
根据PDF 2.0 LTV和PAdES LTV规范，允许为每个签名添加VRI，以便可以验证每个特定签名的相关撤销数据。
知道如何为签名添加VRI字典吗？由于VRI的关键是基本16编码的哈希，这意味着我需要先签名。据我所知（我希望我错了），当具有签名相关信息的PDF保存到输出流中时，将创建签名。 （PDDocument.saveIncremental(ins, outs)）
=============================================== =============
更详细：
当我想根据PAdES LTV和PDF 2.0 LTV规范验证针对DSS数据的签名时，我遇到了这个问题。首先关注的是PDF 2.0 LTV规范。
如果我理解正确：
我遇到的情况： 假设：用户A和用户B有两个用户，他们的证书由相同的CA颁发。 （我认为这很常见。）
签名验证阶段：
当我想重建证书链时，请根据crls和ocsps验证签名证书，特别是当我想检查文件签名时crl未过期时，我需要确保我是使用正确版本的crl。
对我而言，这意味着我应该检查与签名正确映射的certs / crls / ocsps。否则，验证将再次可靠，同样毫无意义。
因此，即使最新的PAdES规范103不建议使用VRI。说真的，我认为这不对....
然后是另一个问题：
正如我评论的那样，我正在使用pdfbox签署pdf。
如果我事先收集DSS数据，请在之后创建签名。 （事实上，DSS也是签名内容的一部分。）
如果我先签署文件，之后获得签名和DSS与VRI，acrobat reader不再识别DSS。我的签名不再是针对acrobat阅读器的LTV。 这是我很困惑的问题。 LTV验证中的acrobat阅读器是错误的还是??
我认为这是错的吗？如果我理解错了，请指出。 提前谢谢！
答案 0 :(得分：0)
首先，我看过的最新PDF 2.0草案已有两年了。因此，我的答案最好是基于ETSI标准，而不是基于该草案。 ;）
如果我理解正确：
- DSS包含我们在签名PDF中的所有签名的吊销数据。
不一定是所有签名。如果验证者仅对单个签名的有效性感兴趣（如果文档中的签名具有不同的语义，则可能是场景），但它应该添加获取的验证相关信息。
当我想重建证书链时，请根据crls和ocsps验证签名证书，特别是当我想检查文档签名时crl是否过期时，我需要确保我＆＃39 ; m使用正确版本的crl。
对我而言，这意味着我应该检查与签名正确映射的certs / crls / ocsps。否则，验证将再次可靠，同样毫无意义。
你的目标究竟是什么？您是否尝试重新制定特定的前验证法案？或者您只是想验证签名？
在前一种情况下，您确实需要一些映射＆＃34;为了验证此签名，使用了以下验证关系信息＆＃34;由例如 VRI 结构。
但通常，后者是您的任务，在这种情况下，您可以使用您找到的任何验证相关信息，只要它适用。因此，在同一CA颁发的签名者证书的样本情况下，只要CRL有效性间隔对签名的验证时间都可以，就可以使用相同的CRL，并且可以正确验证CRL本身的签名。 / p>
因此，
因此，即使最新的PAdES规范103不建议使用VRI。说真的，我认为这不对....
LTV上的PAdES规范只是想保证可以验证签名，而不是像以前那样完全验证它们。考虑到这一任务，这是正确的。
如果我事先收集DSS数据，请在之后创建签名。 （事实上，DSS也是签名内容的一部分。）
好事：acrobat reader识别我的签名是LTV启用。
坏事：在这种情况下，我无法在那里添加VRI。 VRI的关键是签名的散列值。
你不仅没有能力，实际上你不被允许！正如ETSI EN 319 142-1 V1.1.1所说：
任何 VRI 词典都应位于文档增量更新部分。如果签名词典给哪一个 VRI 字典适用于增量更新部分（参见ISO 32000-1 [1]第7.5.6节）， VRI 更新 应在签名更新之后完成。
如果我先签署文件，之后获得签名和DSS与VRI，acrobat reader不再识别DSS。我的签名不再是针对acrobat阅读器的LTV。这是我困惑的问题。 LTV验证中的acrobat阅读器是错误的还是??
这是显示此行为的示例文件有用的地方