什么是“不启用LTV”意思？ [英] What does "Not LTV-enabled" mean?

问题描述

我使用iText 5.5.3为PDF文档签名和时间戳。它工作得很好。但我最近从Acrobat Pro X切换到XI，现在我看到这个新行：

 签名不是LTV在< date>以后过期
  

我想这警告我，在这个日期后，签名者的签名将被视为无效，对吗？然而，签名属性告诉我：签名包括嵌入的时间戳：

 < date / time> 
签名从安全时间戳时间开始生效：< same date / time> 
  

现在我有点困惑：因为签名在已知和认证的日期被宣布有效

解决方案

LTV（长期验证）和PDF签名

支持LTV的

-LTV

电子签名需要数据来验证签名，例如由在线服务（在本文中称为验证数据）通常提供的CA证书，证书撤销列表（CRL）或证书状态信息（OCSP）。如果文档被存储并且签名在首次创建之后很长时间是可验证的，特别是在签名证书过期之后，原始验证数据可能不再可用，或者可能不确定在文档第一次使用什么验证数据

此配置文件使用ISO 32000-1 [...]的扩展名来携带验证签名所需的验证数据

（ ETSI TS 102 778-4 ）

基于PDF规范的此扩展ISO 32000-1 Adob​​e在Acrobat / Reader XI中创建了 LTV-enabled 字样。根据Adobe的PDF宣传员Leonard Rosenthol：

我们的客户要求我们清楚地识别包含LTV的PDF文件）。

不幸的是，这个简单明了的术语

2013年初，Acrobat XI发布几个月后，人们开始想知道为什么他们的签名（在Acrobat X看起来很好看）没有任何限制）突然被批评为不是LTV启用，并很快过期。当时，Leonard在iText邮寄名单上描述了启用LTV的签名PDF ：

启用LTV意味着验证文件所需的所有信息（减去根证书）都包含在内。

另一个Adobe员工，Steven.Madwin，更坦率地说，这样

当您打开Acrobat文件时（当我说Acrobat是指Acrobat& Reader时）进行签名验证。作为验证过程的一部分，它确定是否必须上线以下载撤销信息，或者是嵌入在PDF文件中的所有撤销信息。在这一点上，它知道它将在签名导航面板说什么。如果它必须下载数据，那么签名不是LTV启用的，但如果所有撤销的担保是在文件中，则签名是LTV启用。

一方面，我们有一个简单明了的术语 LTV-enabled 让人觉得这是一个清楚的开/关事项，而在另一方面这个术语的含义取决于Adobe Acrobat和Reader中的（闭合的）签名验证算法。

更糟糕的是，这些算法的行为取决于本地配置Acrobat / Reader！对于任何有效的PDF签名，只需将即时签名者证书添加到手中签名类型的受信任证书即可将Adobe Acrobat和Reader配置为显示为启用LTV的，类似地， 。

LTV启用签名

考虑到上述情况，无法确定PDF您的Acrobat / Reader上的启用LTV功能也会在下一个人的Acrobat / Reader上显示启用LTV的。

据说，你至少可以尽力提供验证者所需的所有撤销信息。包括

• 提供从涉及到所有规范的受信任根证书构建证书路径所需的所有证书;


• 
  

$ b 对所有涉及的签名...并且所有签名包括签署个别CRL，OCSP响应和时间戳的签名！然后添加时间戳，并添加与时间戳相关的证书和吊销信息。

正如Leonard所说，这通常需要使用PAdES第4部分对ISO 32000- 1，文件安全存储（DSS）：

当所有抵押品嵌入签名而不是DSS [ 。]。在这种情况下，可能没有DSS。然而，这是非常不寻常的，因为CRL和OCSP上的签名不包含嵌入的rev信息是Adobe扩展。然而，这是一个遥远的可能性。

启用LTV的 vs。 PDF 1.4

在注释中出现以下问题

但是可以在PDF v1.4中添加DSS

您可以将DSS条目添加到PDF v1.4文档。 PDF 1.4也是符合ISO 32000的PDF 1.7 -1，而DSS是ISO 32000-1的扩展。

是的，但我假设你实际上想知道结果是否仍然是PDF 1.4

这个问题的答案有点含糊，因为是PDF 1.4 没有明确定义：Leonard 一旦显示：

PDF参考文献本质上不是规范性的 - 它们（通常）不会做出最终的，确定的陈述 - 只是一般的陈述。

因此，没有任何规范性指定所有。

这并没有使ISO不使用PDF参考1.4作为他们的PDF / A-1规范的规范基础，所以让我们沿着的PDF参考。 ;）

PDF参考，第三版，Adobe便携式文档格式，版本1.4 在附录E中说明：

生产者或Acrobat插件扩展也可以将密钥添加到实现为字典的任何PDF对象，除了文件尾部字典（见第3.4.4节文件尾部）。

< blockquote>

因此，添加DSS所需的现有字典的添加应该没有问题，添加的间接对象也不应该是它们符合第3节语法

因此，沿着这一行进行论证，添加了DSS的PDF v1.4仍然可以是PDF 1.4。

显然，软件只是了解PDF 1.4

<不能使用DSS信息，但是

• 可能会考虑添加DSS来更改签名文档，导致验证警告或错误。

关于后一项，我假设面对PDF 1.4加DSS，例如Adobe Reader版本5到7警告关于签名后的更改，Adobe Reader版本8和9甚至认为由于更改的签名损坏，并且Adobe Reader X和XI接受添加并使用它愉快。

I'm using iText 5.5.3 to sign and timestamp PDF documents. It works very well. But I recently switched from Acrobat Pro X to XI and now I see this new line :

the signature is not LTV enabled and will expire after <date>

I guess this warns me that after this date, the signer's signature will be seen as invalid, right ? However the signature properties tells me :

the signature includes an embedded timestamp : <date/time>
signature was validated as of the secure timestamp time : <same date/time>

Now I'm a little bit confused : since the signature was declared valid at a known and certified date, why would it become invalid in the future ?

解决方案

LTV (Long Term Validation) and PDF signatures

The term LTV-enabled

4 Profile for PAdES-LTV

4.1 Overview

Validation of an electronic signature requires data to validate the signature such as CA certificates, Certificate Revocation List (CRLs) or Certificate status information (OCSP) commonly provided by an online service (referred to in the present document as validation data). If the document is stored and the signatures are to be verifiable long after first created, in particular after the signing certificate has expired, the original validation data may no longer available or there may uncertainty as to what validation data was used when the document was first verified.

This profile uses an extension to ISO 32000-1 [...] to carry such validation data as necessary to validate a signature.

(ETSI TS 102 778-4)

Based on this extension of the PDF specification ISO 32000-1 Adobe created the term LTV-enabled in Acrobat / Reader XI. According to Leonard Rosenthol, Adobe's PDF evangelist:

Our customers asked that we clearly identify a PDF that contained LTV (vs. one that did not). That was that term that we determined was simple and clear in conveying that message.

Unfortunately this simple and clear term is not really well-defined.

Early 2013, a few months after Acrobat XI has been released, people started wondering why their signatures (which in Acrobat X looked great without any restriction) suddenly were criticized as not LTV enabled and soon to expire. At that time Leonard characterized "LTV-enabled" signed PDFs on the iText mailing list:

LTV enabled means that all information necessary to validate the file (minus root certs) is contained within.

Another Adobe employee, Steven.Madwin, more bluntly put it like this

When you open the file Acrobat (and when I say Acrobat I mean both Acrobat & Reader) does the signature validation. As part of the validation process it figures out if it has to go online to download revocation information, or, is all of the revocation information embedded in the PDF file. At this point it knows what it's going to say in the Signature Navigation Panel. If it had to download data then the signature is not LTV enabled, but if all of the revocation collateral is in the file then the signature is LTV enabled.

So on one hand we have a simple and clear term LTV-enabled making the impression that it is a clear on/off matter, and on the other hand the meaning of the term depends on the (closed) signature verification algorithms in Adobe Acrobat and Reader.

Even worse, the behavior of those algorithms depends on the local configuration of the Acrobat / Reader! For any valid PDF signature Adobe Acrobat and Reader can be configured to show it as LTV-enabled by simply adding the immediate signer certificates to the trusted certificates for the signature type at hands, and analogously the other way around.

LTV-enabling a signature

Considering the above-said one can never be sure whether a PDF showing LTV-enabled on your Acrobat / Reader also shows LTV-enabled on the next person's Acrobat / Reader.

That been said, you can at least do your best to provide all the revocation information required by a verifier. This includes

• providing all the certificates required to build certificate paths from every certificate involved to the canonical trusted root certificates;
• providing revocation information (CRLs / OCSP responses) for all these certificates with the obvious exception of the root certificates;

for ALL signatures involved... and all signatures include the signatures signing individual CRLs, OCSP responses, and time stamps! Then add a time stamp and add certificates and revocation information related to the time stamp.

As Leonard remarks this usually requires the use of the PAdES part 4 extensions to ISO 32000-1, the Document Security Store (DSS):

LTV may be enabled when all collaterals are embedded in the signatures and not DSS [...]. In this case there may be no DSS. However, this is very unusual, because signatures over CRLs and OCSPs do not contain embedded rev info which is Adobe extension. Yet, this is a distant possibility.

LTV-enabled vs. PDF 1.4

In a comment the following question arose

But is it possible to add a DSS in a PDF v1.4

You can add DSS entries to a PDF v1.4 document. A PDF 1.4 also is a PDF 1.7 according to ISO 32000-1, and the DSS is an extension to ISO 32000-1.

Yes, but I assume you actually want to know whether the result still is PDF 1.4.

The answer to this is a bit vague because being PDF 1.4 is not really well defined: As Leonard once put it:

the PDF References aren't "normative" in nature - they don't (usually) make final, definitive statements - just sort of general ones.

Thus, there is nothing "normative" in nature specifying what a PDF 1.4 is at all.

This didn't keep ISO from using the PDF Reference 1.4 as normative base for their PDF/A-1 specification, though, so let us argue along the lines of that PDF Reference anyway. ;)

The PDF Reference, third edition, Adobe Portable Document Format, Version 1.4 says in Appendix E:

A PDF producer or Acrobat plug-in extension may also add keys to any PDF object that is implemented as a dictionary, except the file trailer dictionary (see Section 3.4.4, "File Trailer").

Thus, the additions to existing dictionaries required for adding a DSS should be no problem, nor should the added indirect objects be as they do conform to section 3 Syntax of the PDF Reference.

Arguing along this line, therefore, a PDF v1.4 with the addition of a DSS can still be a PDF 1.4.

Obviously, though, software only understanding PDF 1.4

• cannot, without further ado, make use of the DSS information but
• may consider the addition of DSS a change of the signed document resulting in verification warnings or errors.

Concerning the latter item I would assume that, confronted with a PDF 1.4 plus DSS, e.g. Adobe Reader version 5 through 7 warn about changes after signing, Adobe Reader version 8 and 9 even consider the signature broken due to the changes, and Adobe Reader X and XI accept the addition and use it happily.

这篇关于什么是“不启用LTV”意思？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！