我对这个话题很陌生。我用pkcs# 12数字证书签署了一个PDF文件。在adobereader中，当我打开签名面板时，我可以看到"签名已启用LTV"。读了这篇文章，我真的不明白，我是否需要应用时间戳。如果没有，如何验证应用签名的时间?或者我应该添加什么样的验证信息?
术语LTV enabled
首先是LTV enabled是Adobe引入的一个术语，没有适当指定。特别是而不是与术语相同，具有LTV的PDF文档ETSI在其PAdES规范第4部分(ETSI TS 102 778-4)中使用。
Steven Madwin(当时受雇于Adobe)曾经这样说过:
因此，该术语的含义取决于当你打开文件Acrobat(我说的Acrobat指的是Acrobat &;Reader)执行签名验证。作为验证过程的一部分，它确定是否必须在线下载吊销信息，还是将所有的吊销信息嵌入到PDF文件中。在这一点上，它知道它要在签名导航面板中说什么。如果它必须下载数据，那么签名是不支持LTV的，但是如果所有的撤销抵押品都在文件中，那么签名是支持LTV的。
- Adobe的验证码和
- 代码使用的相关安全设置。
有关其他背景，请参阅此答案。
OP的案例
OP观察到
我已经用pkcs# 12数字证书签署了PDF文档。在adobereader中，当我打开签名面板时，我可以看到"签名已启用LTV"。
并在注释中解释
我的证书必须是自签名的
和
我已将证书导入Internet选项中的"受信任的根证书颁发机构"。
根据其安全设置，adobeacrobat/Reader可能会自动信任在其运行的操作系统中配置为受信任根的证书。这似乎是op的情况。
因此，OP的签名者证书是其系统上Adobe验证者的可信根证书。因此，在验证他的签名时不需要额外的验证相关信息，并将其称为LTV enabled。
但是，在另一个人的计算机上，有问题的证书不受信任，Adobe验证器无法验证签名，更不用说调用它LTV enabled。
自签名证书和LTV
LTV对于使用自签名证书签名的签名几乎没有任何意义，特别是没有可能添加到文档中的相关撤销信息。
为什么?这是由于这里使用的信任模型。
它基本上是分层的:
- 我们首先信任一些机构(证书颁发机构)，我们通过在我们的应用程序或操作系统中注册它们的根证书来无条件地信任它们。
- 我们进一步信任所有由受信任证书颁发的证书(即，如果受信任证书未标记为最终实体证书)。
这听起来很棒，直到人们意识到其中一些证书的私钥迟早会被泄露。显然，我们不想再信任这种被破坏的证书了。在上面的基本模型中，这意味着我们必须撤销对直接或间接颁发受损害证书的根证书的信任。由于这个根可能直接或间接地颁发了数百万个证书，因此这是不可取的。
所以我们通过添加撤销检查服务来扩展基本模型:
- 我们再次从信任一些机构(证书颁发机构)开始，我们通过在我们的应用程序或操作系统中注册它们的根证书来无条件地信任它们。
- 我们进一步信任由受信任证书颁发的所有证书(即，如果受信任证书未标记为最终实体证书)，除非与颁发证书相关联的吊销检查服务表明该证书已被吊销。
这听起来很棒，直到人们意识到这些撤销检查服务可能会停止工作(例如，因为运行有问题的证书颁发机构的公司倒闭了)。至少那些长期被关注的文件上的签名存在无法通过这种方式验证的风险。
为了解决这个问题，引入了LTV(长期验证)机制。它们基本上收集从受信任根到签名者证书的证书链，以及来自除根证书之外的所有证书的吊销检查服务的响应，并将它们与签名捆绑在一起。(根证书必须仍然是显式可信的。)
使用这些信息，可以在证书颁发机构停止提供撤销检查服务很久之后验证签名。(这有点简化;特别是必须考虑发布、签署、撤销和验证时间。但它应该给一个想法…)
所以回到最初的声明，LTV对于用自签名证书签名的签名几乎没有任何意义:自签名证书是人们要么显式信任要么根本不信任的根证书。没有其他根、中介或最终实体感兴趣的证书，也没有可供他们收集的撤销检查响应。
更重要的是，没有什么有趣的可以放入PAdES的LTV验证相关信息。唯一感兴趣的LTV操作是添加文档时间戳(上面没有解释)来缩小签名时间。这是否意味着使用自签名证书我永远无法获得PAdES LTV兼容的pdf?