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

查看:43
本文介绍了“未启用 LTV"是什么意思?意思是?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用 iText 5.5.3 对 PDF 文档进行签名和时间戳记.它工作得很好.但我最近从 Acrobat Pro X 切换到 XI,现在我看到了这条新线:

签名未启用 LTV,将在 <date> 之后过期.

我想这会警告我,在此日期之后,签名者的签名将被视为无效,对吧?但是签名属性告诉我:

签名包含一个嵌入的时间戳:<date/time>签名在安全时间戳时间得到验证:<相同的日期/时间>

现在我有点困惑:既然签名在一个已知且经过认证的日期被宣布为有效,为什么它会在未来变得无效?

解决方案

LTV(长期验证)和 PDF 签名

术语启用LTV

<块引用>

4 PAdES-LTV 配置文件

4.1 概述

电子签名的验证需要验证签名的数据,例如 CA 证书、证书撤销列表 (CRL) 或通常由在线服务提供的证书状态信息 (OCSP)(在本文档中称为验证)数据).如果文档被存储并且签名要在首次创建很久之后进行验证,特别是在签名证书过期之后,则原始验证数据可能不再可用,或者可能不确定文档最初使用时使用了什么验证数据已验证.

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

(ETSI TS 102 778-4)

基于 PDF 规范 ISO 32000-1 的此扩展,Adobe 在 Acrobat/Reader XI 中创建了术语LTV-enabled.Adobe 的 PDF 传播者 Leonard Rosenthol 表示:

<块引用>

我们的客户要求我们清楚地识别包含 LTV 的 PDF(相对于不包含 LTV 的 PDF).这就是我们确定的用于传达该信息的简单明了的术语.

不幸的是,这个简单明了的术语并没有很好的定义.

2013 年初,在 Acrobat XI 发布几个月后,人们开始想知道为什么他们的签名(在 Acrobat X 中看起来很棒,没有任何限制)突然被批评为没有启用 LTV,并且很快到期.当时伦纳德特点是启用LTV";iText 邮件列表中的签名 PDF:

<块引用>

启用 LTV 意味着验证文件所需的所有信息(减去根证书)都包含在其中.

另一位 Adob​​e 员工 Steven.Madwin更直白地说是这样

<块引用>

当您打开文件 Acrobat 时(当我说 Acrobat 时,我的意思是 Acrobat 和 Reader)会执行签名验证.作为验证过程的一部分,它会确定是否必须在线下载吊销信息,或者是否所有吊销信息都嵌入在 PDF 文件中.在这一点上,它知道它会在签名导航面板中说什么.如果它必须下载数据,则签名未启用 LTV,但如果所有撤销抵押品都在文件中,则签名已启用 LTV.

因此,一方面我们有一个简单明了的术语 LTV-enabled 给人的印象是它是一个明确的开/关问题,另一方面该术语的含义取决于 Adob​​e Acrobat 和 Reader 中的(封闭的)签名验证算法.

更糟糕的是,这些算法的行为取决于 Acrobat/Reader 的本地配置!对于任何有效的 PDF 签名,Adobe Acrobat 和 Reader 可以配置为将其显示为LTV-enabled,只需将直接签名者证书添加到手头签名类型的受信任证书中,反之亦然.

启用 LTV 的签名

考虑到上述情况,永远无法确定在您的 Acrobat/Reader 上显示 LTV-enabled 的 PDF 是否也在下一个人的 Acrobat/Reader 上显示 LTV-enabled阅读器.

话虽如此,您至少可以尽力提供验证者所需的所有撤销信息.这包括

  • 提供构建从涉及的每个证书到规范可信根证书的证书路径所需的所有证书;
  • 为所有这些证书提供撤销信息(CRL/OCSP 响应),根证书明显除外;

对于涉及的所有签名...并且所有签名都包括签名单个 CRL、OCSP 响应和时间戳的签名!然后添加时间戳,并添加与时间戳相关的证书和吊销信息.

正如 Leonard 所说,这通常需要使用 PAdES 第 4 部分对 ISO 32000-1 的扩展,即文档安全存储 (DSS):

<块引用>

当所有抵押品都嵌入签名而不是 DSS [...] 时,可以启用 LTV.在这种情况下,可能没有 DSS.但是,这是非常不寻常的,因为 CRL 和 OCSP 上的签名不包含 Adob​​e 扩展的嵌入式 rev 信息.然而,这是一种遥远的可能性.

启用 LTVvs. PDF 1.4

在评论中出现了以下问题

<块引用>

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

您可以将 DSS 条目添加到 PDF v1.4 文档.根据 ISO 32000-1,PDF 1.4 也是 PDF 1.7,DSS 是 ISO 32000-1 的扩展.

是的,但我假设您确实想知道结果是否仍然是 PDF 1.4.

这个问题的答案有点模糊,因为 PDF 1.4 的定义并不明确:正如 Leonard 曾经放过:

<块引用>

PDF 参考不是规范的";在本质上——它们(通常)不会做出最终的、明确的陈述——只是一般的陈述.

因此,没有任何规范".本质上指定PDF 1.4是什么.

不过,这并没有阻止 ISO 使用 PDF 参考 1.4 作为其 PDF/A-1 规范的规范基础,所以无论如何,让我们按照该 PDF 参考的思路进行争论.;)

PDF 参考,第三版, Adob​​e Portable Document Format, Version 1.4 在附录 E 中说:

<块引用>

PDF 生成器或 Acrobat 插件扩展也可以向任何作为字典实现的 PDF 对象添加键,文件尾字典除外(请参阅第 3.4.4 节,文件尾").

因此,添加 DSS 所需的现有字典的添加应该没有问题,添加的间接对象也不应该符合 PDF 参考的第 3 节 语法.

因此,沿着这条线争论,添加了 DSS 的 PDF v1.4 仍然可以是 PDF 1.4.

但显然,软件只能理解 PDF 1.4

  • 不能直接使用 DSS 信息,但是
  • 可能会将添加 DSS 视为更改已签名文档,从而导致验证警告或错误.

关于后一项,我会假设,面对 PDF 1.4 plus 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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆