PAdES 基线配置

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

概览

PAdES 定义了四个基准层级——B-B、B-T、B-LT、B-LTA——彼此层层堆栈建立在前一层之上。每一层都会增加一种特定形式的证据。本页说明这段递进关系，帮助你选择仍能满足该义务的最低层级，而不是选择那个你刚好听过名字的最高层级。

为何重要

有些人选择「B-LTA」，只是因为它听起来最周全；也有人选择「B-B」，只是因为它最省事。这两种做法都只是猜测。决定你所需层级的，不是偏好，而是一个问题：这份签名必须维持可验证多久，又必须由谁来验证？ 选得太低，原本在签署当天有效的签名，会在凭证到期时变得无法验证。选得太高，你就要承担并不需要的时间戳机构与验证材料基础设施，以及一项必须持续维护的封存义务。一旦层级无法再变更，日后就得为错误的层级付出代价。

精简版说明

• 这四个层级是累积的。每一层都在前一层基础上再增加一项内容。
• B-B——附带必要签署属性的签名。证明是谁以及签了什么。
• B-T——B-B 再加上一个对该签名的受信任时间戳。不依赖签署者的时钟，证明何时签署。
• B-LT——B-T 再加上内嵌的验证材料（凭证与撤销数据）。文档自行携带证据，证明凭证在签署当时是有效的。
• B-LTA——B-LT 再加上一个文档时间戳，并随时间重复施加。让整份内容跨越数十年与算法变迁后仍保持可验证。
• 依据义务的存续期间来选择层级，而不是看哪个选项最安全。

NextPDF 的处理方式

NextPDF 将层级建模为一个明确且有序的选择，并且拒绝假装。你请求某个层级，引擎就会产生恰好那个层级；否则，它会以可操作的错误失败。它不会悄悄以较低层级签署，却让合规记录宣称为较高层级。这套设计的目的，正是防止在基础设施缺失时，把一个 B-LTA 的请求悄悄降级为 B-T。每个层级的需求都会编码为谓词：是否需要时间戳、是否需要内嵌的验证材料、是否需要文档时间戳。引擎会逐一检查这些谓词，要么全部满足，要么停止。

下方的递进关系，正是引擎强制执行、也由标准定义的那一套。

层级	相对前一层所添加的内容	它所回答的问题	对你的部署有何需求
B-B	签署属性：content-type、message-digest、signing-time、signing-certificate-v2	是谁签署的，以及确切是哪些字节？	一把签署密钥与一张凭证
B-T	一个涵盖签名值的受信任时间戳	它是何时签署的，可被证明吗？	一个时间戳机构（TSA）
B-LT	内嵌的凭证与撤销数据（一个 DSS）	凭证在签署当时是否有效——日后能否证明？	TSA，以及在签署当时能访问撤销数据的管道
B-LTA	一个可随时间更新的文档时间戳	这份内容在数十年后是否仍可验证？	TSA，以及一套可重新施加时间戳的封存流程

最关键的跨越是从 B-T 到 B-LT。B-T 证明何时。B-LT 让文档在信任方面自给自足：它不再依赖某个凭证机构多年后仍然可连接并回应查询。

1. Step 1 of 4: ISO 32000-2 §12.8 — signatures, LTV, document timestamp ISO 32000-2 §12.8 — signatures, LTV, document timestamp
2. Step 2 of 4: ETSI EN 319 142-1 PAdES baseline levels B-B…B-LTA ETSI EN 319 142-1 PAdES baseline levels B-B…B-LTA
3. Step 3 of 4: RFC 3161 Timestamp token (introduced at B-T) RFC 3161 Timestamp token (introduced at B-T)
4. Step 4 of 4: RFC 6960 OCSP revocation evidence (embedded at B-LT) RFC 6960 OCSP revocation evidence (embedded at B-LT)

PAdES 递进过程背后的标准：ISO 32000-2 定义了签名与验证材料如何置于 PDF 之中；ETSI EN 319 142-1 定义了各个基准层级；RFC 3161 定义了 B-T 所引入的时间戳；RFC 6960 定义了 B-LT 所内嵌的撤销证据。

证据怎么说

Evidence § Standard-backed Evidence: Standard-backed 层级定义来自 ETSI。 Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 定义了 PAdES 基准层级； Spec Spec: ETSI EN 319 142-2, §5.3 ETSI EN 319 142-2 §5.3 将 signature-time-stamp 属性标示为可选元素；它是否存在，正是区分带时间戳层级与 B-B 的关键。 Spec Spec: ETSI EN 319 142-2, §6.3.2.2 ETSI EN 319 142-2 §6.3.2.2 则指出，一个受信任的时间戳应在签名创建后立即施加，使记录的时间尽可能接近真实签署时间。 Spec Spec: ETSI EN 319 142-2, §5.5 ETSI EN 319 142-2 §5.5 指出，长期行为同时需要一个文档安全保存区与文档时间戳—— 也就是 B-LT 与 B-LTA 所添加的内容。

容器层面则由 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），恰如 ETSI EN 319 142-1 所描述的那样。B-LT 的重要性，可由 Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 所阐明：已封存的撤销证据有助于证明该签名在其产生当天是可信的，即使该凭证早已过期。这正是将其内嵌的全部用意。

NextPDF 的引擎将每个层级编码为一个需求谓词，并产生所请求的层级，否则便失败——它绝不会宣称一个它并未创建的层级。

Human-factors note: Human-factors note

本页先给出决策规则——依义务的存续期间来选择—— 再进入任何层级细节，因为这才是多数读者真正需要的信息。只读过「精简版说明」的读者，理应已经能够做出正确选择。各层级的运作机制，是给那些需要为选择辩护的读者，而不是用来把关选择本身。

实务范例

API 也体现这段递进关系：你指定一个层级，引擎就将其视为一份契约。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// The level is an explicit, ordered choice — not a flag you hope is honoured.
$level = SignatureLevel::PAdES_B_T;

// The level itself tells you what it requires, before you sign:
$level->requiresTimestamp();          // B-T and above → true
$level->requiresDss();                // B-LT and above → true
$level->requiresDocumentTimestamp();  // B-LTA only     → true

// Ask for B-LTA only if the deployment can actually fulfil it.
// The engine produces exactly the requested level or fails with an
// actionable error — it never silently signs lower and reports higher.

如果你请求 B-LTA，但部署无法提供 B-LTA 所需的内容，默认行为是失败，并告诉你它本来能达到的最高层级——而不是悄悄回传一份标示为 B-LTA 的 B-T 文件。

常见误解

常见陷阱是：「B-LTA 就是最好的那一个，永远选它就对了。」B-LTA 并非抽象意义上的「更好」；它是更多，而更多就意味着义务。它需要一个时间戳机构、在签署当时收集的撤销材料，以及一套持续运行的封存流程，在文档的保护算法或时间戳凭证变弱之前为文档重新施加时间戳。一份没有人为其重新施加时间戳的 B-LTA 文件并非面向未来——它只是一份多了一套仪式的 B-LT 文件。反过来说，为一份必须存续十年的合约选用 B-B 并不「轻量」；它是一份在凭证到期当天就会验证失败的签名。正确的层级就是该义务所要求的那一个，不高也不低。

限制与边界

NextPDF 会生成所请求的 PAdES 层级；但它并不提供该层级所依赖的各方。时间戳机构、凭证链、信任锚点，以及在签署当时取得撤销数据的连接能力，都属于部署方的职责。引擎实现了相关结构并强制执行层级契约；它无法让一个 TSA 变得值得信任，也无法让一张凭证变得有效。生成的结构承载了该层级所要求的各项元素，并已根据引擎自身测试和所引用条款进行验证。这并非第三方一致性认证，本页也并未主张 eIDAS 下的法律效力；后者取决于凭证、签署者以及管辖区。签署时间是否获得独立信任，相关说明请见 时间戳与受信任时间；至于长期证据如何让一份签名持续可验证，相关说明请见 长期验证。

以下边界用于准确设置预期：

• B-LT 与 B-LTA 发出的是长期验证的结构，而非一致性裁定。 引擎所写入的是一个文档安全保存区字典，外加一笔文档时间戳修订——一个 Type = DocTimeStamp 的签名字典，遵循 Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 。此处并未将该结构标榜为已通过配置一致性测试；ETSI EN 319 142-1 配置检查在 Pro 与 Enterprise 的 CI 通道中作为发布门禁执行，因此本页并未就所产生的文件主张 ETSI EN 319 142-1 一致性。
• 加密文档对于 B-LT 与 B-LTA 采取失败即关闭。 对一份加密文档请求长期层级，会以可操作的错误停止，而不会写入一笔不完整的长期修订。

各层级的版本可用性如下——四者都通过同一个高层接口实现，即 setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()：

PAdES baseline level — edition availability

Edition	Availability
Core	○ PAdES B-B——签署属性基准；也就是 Core 接口。
Pro	○ 新增 PAdES B-T——一个涵盖签名值的受信任时间戳，由一个 TsaClient 驱动。
Enterprise	○ 新增 PAdES B-LT 与 B-LTA——内嵌的验证材料（DSS），以及可更新的文档时间戳封存循环。 这些都通过同一个高层接口运作，但仅在 Pro 与 Enterprise 套件两者 皆已安装时才可用；只要任一者缺失，该调用便会失败即关闭，而不会写入一笔不完整的长期修订。

相关文档

• 签名在 PDF 中的存放方式——各层级建立其上的字节范围与字典基础。
• 长期验证——B-LT 与 B-LTA 实际内嵌哪些内容，以及为什么一份有效签名缺少它们时，日后可能验证失败。
• 时间戳与受信任时间——RFC 3161 所引入、并由 B-LTA 更新的 B-T 时间戳。
• 签署协议工作流程——让选定的 PAdES 基准层级在实际流程中发挥作用的具体工作流程。

词汇表

• PAdES——PDF Advanced Electronic Signatures（PDF 高级电子签名）；即为 PDF 定义 CMS 签名配置的 ETSI EN 319 142 系列标准。
• 基准层级——B-B、B-T、B-LT、B-LTA 之一；一组已定义且累积的必要签名元素。
• B-B——附带必要签署属性的基准签名。
• B-T——B-B 再加上一个涵盖签名值的受信任时间戳。
• B-LT——B-T 再加上内嵌的长期验证材料（一个 DSS）。
• B-LTA——B-LT 再加上一个可更新的文档时间戳，以维持封存有效性。
• DSS——Document Security Store（文档安全保存区）；用于存放内嵌凭证与撤销数据的 PDF 结构。
• TSA——Time-Stamp Authority（时间戳机构）；一个发行 RFC 3161 时间戳令牌的受信任服务。