我对这个话题很新。我已经签署了带有PKCS＃12数字证书的PDF文档。在Adobe Reader中，当我打开签名面板时，我可以看到＆＃34; Signature已启用LTV＆＃34;。阅读this文章，我无法理解，是否需要应用时间戳。如果没有，我如何验证签名的应用时间？或者我应该添加什么样的验证信息？
答案 0 :(得分：1)
首先，术语启用LTV 是Adobe引入的术语，未正确指定。特别是它与ETSI在其PAdES规范第4部分（ETSI TS 102 778-4）中使用的术语不具有LTV 的 相同。
Steven Madwin（当时受雇于Adobe）once put it like this：
当你打开文件Acrobat（当我说Acrobat我的意思是Acrobat和读者）时，会进行签名验证。作为验证过程的一部分，它确定是否必须联机下载吊销信息，或者是PDF文件中嵌入的所有吊销信息。此时，它知道它将在签名导航面板中说出什么。如果必须下载数据，那么签名不是LTV启用的，但如果所有撤销附属品都在文件中，则签名是LTV启用的。
因此，该术语的含义取决于
有关其他背景，请参阅this answer
OP观察
我已经使用PKCS＃12数字证书签署了PDF文档。在Adobe Reader中，当我打开签名面板时，我可以看到＆＃34; Signature已启用LTV＆＃34;。
并在评论中解释
我的证书必须是自签名的
和
我已将证书导入＆＃34;受信任的根证书颁发机构＆＃34;在互联网选项中。
根据其安全设置，Adobe Acrobat / Reader可能会自动信任在其运行的操作系统中配置为受信任根的证书。这似乎是OP的情况。
因此，OP的签名者证书是其系统上Adobe验证者的可信根证书。因此，在验证其签名时，它们不需要额外的验证相关信息，并将其称为 LTV已启用。
在另一个人的计算机上，有问题的证书尚未被信任，Adobe验证人无法验证签名，更不用说将其称为 LTV启用。
为什么呢？这是由于此处使用的信任模型。
它基本上是分层的：
这听起来很棒，直到有人意识到某些证书的私钥迟早会受到损害。显然，我们不想再相信这些受到侵害的证书了。在上面的基本模型中，这意味着我们必须撤销对直接或间接发布被破坏的根证书的信任。由于根可能直接或间接发布数百万和数百万个证书，因此这是不可取的。
所以我们通过添加撤销检查服务来扩展基本模型：
这听起来很棒，直到有人意识到这些撤销检查服务可能会停止工作（例如，因为运行相关证书颁发机构的公司破产）。至少长期感兴趣的文件签名有可能以这种方式变得无法验证。
为了解决这个问题，引入了LTV（长期验证）机制。它们基本上从受信任的根到签名者证书以及来自除根证书之外的所有人的撤销检查服务的响应收集证书链，并将它们与签名捆绑在一起。 （必须仍明确信任根证书。）
使用这些信息可以在证书颁发机构停止提供吊销检查服务之后很久就验证签名。
（这有点简化;特别是必须考虑签发，签署，撤销和验证时间。但它应该提出一个想法......）
回到最初声称 LTV对使用自签名证书签名的签名几乎没有任何意义：自签名证书是根证书，其中一个明确信任或根本不信任。没有其他感兴趣的根，中介或最终实体证书，也没有撤销检查回复，供他们收集。
这是否意味着使用自签名证书我永远无法获得符合PAdES LTV标准的pdf？
更重要的是，没有任何兴趣将放入PAdES LTV验证相关信息。唯一感兴趣的LTV操作是添加文档时间戳（上面没有解释）以缩小签名时间。