长期验证

Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 Spec Spec: RFC 6960 RFC 6960 Spec Spec: ISO 32000-2, §12.8.4 ISO 32000-2 §12.8.4 Evidence § Standard-backed Evidence: Standard-backed

概览

你今天验证的签名，建立在不会永久存在的事实之上：会过期的证书、可能下线的撤销服务器，以及会随时间变弱的哈希算法。长期验证会趁证据仍可取得时，将其记录到文件中。这样，多年之后仍然可以检验该签名，而无需再向任何人查询信息。

为什么这很重要

数字签名的危险之处在于，它可能悄悄变得无法验证，外观却看不出任何变化。文件中的内容没有改变。证书颁发机构不再响应某张早已过期证书的查询。需要该响应的验证器再也无法取得它。一份在签署当天毫无疑问有效的合约，十年后却变成「无法判定」。而十年之后，往往正是最可能发生争议、影响也最重大的时候。如果你的保存义务以年为单位衡量，那么缺少长期验证的签名，就是一项要到日后才会浮现的风险。

简短版本

• 签名的有效性取决于有时效性的外部事实：证书的有效期，以及来自服务器的撤销状态。
• 证书过期之后，这些事实便可能无法取得——颁发机构没有永久响应的义务。
• 长期验证会在签署当下捕获证据——证书、OCSP 响应、CRL——并将其嵌入文件的**文件安全存储区（DSS）**之中。
• 接着由一个文件时间戳证明证据本身在那一刻确实存在且有效，并可在其自身保护变弱之前加以更新。
• 其结果是：文件本身就带有证明。验证不再取决于某个服务器是否仍然存在。

NextPDF 的处理方式

原则很简单：「趁还能收集时就收集证明，然后将它封存起来」。当 NextPDF 产生长期签名时，会收集证书链以及撤销响应，借以证明签署证书在签署当下状态良好。它会将这些内容以嵌入值（而非链接）的形式写入 DSS。接着，它会在整体之上加上一个文件时间戳。关键正是嵌入值。指向撤销服务器的链接，正是长期验证要消除的那种依赖。

这些长期验证层会以单独的文件修订版本写入，通过附加方式加入，而不会扰动原始签名的字节范围。第一个签名始终保持可验证。长期数据是加在它周围，而不是加入它之中。当文件时间戳本身的保护随时间衰退时，封存等级允许在其上再叠加另一个时间戳。最终形成一条链，其中每个时间戳都为其下的所有内容背书。

1. Sign The signature and its signed attributes are written (B-B).
2. Capture evidence Certificate chain, OCSP responses, and CRLs proving the certificate was valid at signing time are gathered.
3. Embed in the DSS The evidence is written into the document as embedded values, not links (B-LT).
4. Seal with a document timestamp A timestamp proves the embedded evidence existed and was valid at that moment (B-LTA).
5. Renew before it weakens Another timestamp is layered before the previous one’s protection ages, extending verifiability.

长期验证如何让签名在时间推移中维持可验证：先建立签名，趁证据还能取得时加以捕获，再以文件时间戳将证据封存，并在封存变弱之前加以更新。

证据说明了什么

Evidence § Standard-backed Evidence: Standard-backed 这项需求在 Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 ：OCSP 响应方可在证书过期后仍保留撤销信息，而封存截止日期则让应用程序得以证明某个签名在其产生当天是否可靠——即便验证它所需的证书早已过期也是如此。这正是长期验证存在的全部理由。撤销响应只在有限时间内保持可用，因此你必须在那段时间结束前加以捕获。

这套机制来自 ETSI。 Spec Spec: ETSI EN 319 142-2, §5.5 ETSI EN 319 142-2 §5.5 指出长期行为需要一个文件安全存储区，以值的形式承载验证数据，并接着加上一个文件时间戳。 Spec Spec: ISO 32000-2, §12.8.3.3 ISO 32000-2 §12.8.3.3 将其串联在一起： PAdES 即 CAdES CMS 与长期验证（§12.8.4）以及文件时间戳字典（§12.8.5）的结合。而且 Spec Spec: ETSI EN 319 142-2, §6.3.2.2 ETSI EN 319 142-2 §6.3.2.2 也说明了为什么时间戳要及早加上：它应在签署后立即应用，好让所记录的时间尽可能贴近真实时间。

NextPDF 的引擎将它实现为 B-LT 与 B-LTA 等级：嵌入 DSS 中的撤销值、封存这些值的文件时间戳，以及更新该封存的封存循环——以附加修订版本的形式写入，使原始签名的字节范围保持完整不变。

Human-factors note: Human-factors note

最重要的信息——趁证据还能取得时就加以捕获，因为日后就无法取得——会在任何 DSS 机制细节之前先说明，因为对于安全相关主题而言，警告应放在程序之前。读者只要明白撤销证据有其可取得期限，就已经掌握了那个能避免十年后失效的关键点。

实际范例

你选择的等级就是长期验证决策本身。API 会在你确认之前，先明确展示这项要求。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;

$level->requiresDss();                // true  → certificates + revocation embedded
$level->requiresDocumentTimestamp();  // true  → a document timestamp seals the DSS

// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
    ->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
    ->save();

// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

上方所示的高层接合点——setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()——如今已端到端实现；先前的版本虽然暴露了等级枚举，却没有提供产生它的接合点。它写入的是那个结构：DSS 字典，以及由 Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 所描述的 DocTimeStamp 修订版本。该结构并未经过配置文件符合性测试，且该接合点不会对 ETSI 符合性或法律有效性作出任何断言。B-LT 与 B-LTA 等级需要 Pro 与 Enterprise 两者；在其他任何方案上，该接合点会以失败封闭（fail closed）方式处理，而不是产生部分结果。对于加密文件，B-LT 与 B-LTA 同样以失败封闭方式处理——宁可不在加密内容之上写入 DSS 与文件时间戳，也不会错误地写入。

这项选择无法在事后以低成本补做。撤销证据必须在签署当下、趁响应仍然可用时加以捕获。决定「我们日后再加上长期验证」，通常就等于决定「等到我们需要时，手上不会有证据。」

常见的误解

第一个误解是「长期验证会让签名永远有效」。它并不会让任何东西变得有效。它保留的是验证能力，用于检验在签署当下就已确立的有效性。如果文件签署时证书就已遭撤销，嵌入这项事实也挽救不了该签名，反而会把这次失效永久记录下来。长期验证是一种保存证明的机制，而不是建立证明的机制。第二个误解是认为 B-LTA 是「设置后即可置之不理」。封存时间戳所用来保护的算法，本身也会随时间老化。若不加以更新，一份 B-LTA 文件终究会继承它原本试图摆脱的那种脆弱性。

限制与边界

NextPDF 会收集并嵌入证据，并写入时间戳。它并不控制证据的真实性，也不负责证据的更新排程。撤销响应的可信度，取决于发出它们的颁发机构，以及取得它们的那一刻。在签署当下与该颁发机构的连接能力，属于部署层面的责任。引擎无法凭空生成一个它取得不到的撤销响应。封存更新是一项运营性程序。引擎可以再加上一个时间戳，但无法决定你的保存政策何时要求这样做。嵌入的数据日后是否被判定为充分，是一个关于验证器与政策的问题，这在 正确验证签名 中说明。本页面并不主张法律上的可采纳性，它取决于司法管辖区、签署者以及证书。

长期验证的方案可用性：

Long-term validation (DSS embedding and the archival timestamp loop) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T——加在签名值上的受信任时间戳——可用，但嵌入的验证数据（DSS）并不属于 B-T 的一部分。
Enterprise	○ PAdES B-LT 与 B-LTA：嵌入 DSS 中的证书与撤销值、进行封存的文件时间戳，以及可更新的封存循环。

相关文件

• PAdES 基准配置文件——说明 B-LT 与 B-LTA 在等级演进中的位置，以及各自所增加的内容。
• 时间戳与受信任时间——封存所嵌入证据的文件时间戳。
• 正确验证签名——验证器如何使用所嵌入的数据，以及为什么单凭「有效」并不完整。
• 已签署协议工作流程——在实践中应用长期验证数据的端到端工作流程。

词汇表

• 长期验证（LTV）——嵌入验证签名所需的证据，使日后的验证不再依赖外部服务。
• 文件安全存储区（DSS）——用于承载长期验证所需的嵌入证书与撤销数据的 PDF 结构。
• OCSP 响应——关于某张证书在某个时间点撤销状态的已签署声明（在线证书状态协议，RFC 6960）。
• CRL——证书撤销列表；列出已撤销证书的已签署列表。
• 文件时间戳——应用于整份文件的 RFC 3161 时间戳，用以证明所嵌入的证据在当时确实存在且有效。
• 封存循环——在前一个文件时间戳的保护变弱之前，反复加上新的文件时间戳，以延长可验证性。