跳转到内容
getnextpdf.com

Enterprise 版本

Signature — 深度参考

这是 NextPDF Enterprise 长期生产者的深度参考:一个 B-LT 或 B-LTA 签名如何被组装、吊销材料如何被收集与强制、文件时间戳如何为文件锚定时间,以及 Pro 边界如何被强制执行。它处于行为层面与契约层面。具体的 Enterprise 实现类型在此刻意不予命名;本页仅引用公开包与 Core 契约范围。

此能力随 NextPDF Enterprisenextpdf/enterprise)交付,并以 Enterprise 层级的许可信封激活。没有该授权的部署不会加载此能力的类。比较各版本并获取许可

规范的级别→层级矩阵:B-B 是由 Core、Pro 与 Enterprise 共同产出的基线;B-T(带时间戳)由 Core、Pro 与 Enterprise 产出——Core 附带 RFC 3161 时间戳路径,因此 B-T 不需要 premium 包;B-LTB-LTA(DSS、VRI、文件时间戳)仅由 Enterprise 产出。在仅有 Pro 的部署中,请求 B-LT 或 B-LTA 会失败关闭:当 Enterprise 长期生产者缺失时,Core 的 SignatureLevel::isAvailableInEnvironment 返回 false,且 Core 编排器引发一个命名错误,而非静默降级级别。

PAdES levelAddsProducer edition
B-B带已签名属性的 CMS 签名Core, Pro, Enterprise
B-T对签名值施加的可信 RFC 3161 时间戳Core, Pro, Enterprise
B-LT带验证材料的 Document Security StoreEnterprise only
B-LTA覆盖 DSS 的文件时间戳(归档循环)Enterprise only

一个 B-LT 签名是一个 B-T 签名加上一个 Document Security Store。DSS 是一个 Catalog 级字典,持有签名证书过期后验证者所需的证书、OCSP 响应与 CRL 流——ISO 32000-2 §12.8.4.3。长期验证使用两种字典类型——一个 DSS 和一个文件时间戳字典——ISO 32000-2 §12.8。CMS 签名本身以 DER 编码存储在 /Contents 中——ISO 32000-2 §12.8.1。

一个 B-LTA 签名在整份文件状态(包括 DSS)之上追加一个文件时间戳,并通过文件时间戳字典写入——ISO 32000-2 §12.8.5。ETSI EN 319 142-2 描述了相同的长期组合——§5.5——以及处理器支持——§6.3.3.3。

  1. 构建证书链。 签名证书加上调用方提供的任何中间证书构成证书链,签名者在前,朝向信任锚——RFC 5280 §6.1。
  2. 收集吊销材料。 对每张非根证书,生产者先查询 OCSP。一个 OCSP 响应报告 goodrevokedunknown——RFC 6960 §2.2——并由 thisUpdate/nextUpdate 进行时间限定——RFC 6960 §4.2。若 OCSP 不可用,则回退到 CRL,并支持 delta-CRL;一个基础 CRL 与一个可选的 delta 作为独立的 DSS 条目加入。
  3. 写入 DSS。 证书、OCSP 响应与 CRL 作为各自独立的 PDF 流对象写入;重复项按内容哈希去重。DSS 字典通过 /Certs/OCSPs/CRLs 引用它们。
  4. 逐签名 VRI(需主动启用)。 一个 VRI 条目,以该签名 /Contents 值的大写哈希为键,索引该签名对应的具体证书/OCSP/CRL,并带一个可选的验证时刻条目。VRI 默认关闭:ETSI EN 319 142-1 V1.2.1 §5.4 建议新文件不要在 DSS 中使用 VRI;某些验证器在有 VRI 时仍能更好地显示长期状态,因此它可由调用方启用。
  5. 文件时间戳(B-LTA)。 在 DSS 写入之后,一个带 /SubFilter /ETSI.RFC3161/DocTimeStamp 字典连同 ByteRange 与 /Contents 占位符一并追加。整份文件组装完成后,生产者计算 ByteRange 上的 SHA-256 摘要,请求一个 RFC 3161 token——§2.4.1——并嵌入该 DER token;genTime 是 UTC 下的 token 创建时刻——§2.4.2。

生产者按以下优先级解析一种强制模式:一个显式的结构化强制模式优先;否则一个显式的(已弃用的)布尔值映射为 strict 或 permissive;否则默认为 strict(失败关闭)

在 strict 强制下,任何非根证书缺失 OCSP 响应且缺失 CRL 会引发一个错误,而非仅发出一条警告。失败关闭这一默认值的存在,是为了避免在 DSS 中没有任何吊销材料的情况下却仍宣称长期级别地产出一个 “B-LT” PDF。permissive(仅警告)工作流程必须被显式启用。在 strict-offline 网络策略下,不发生任何 OCSP/CRL 抓取;仅使用 DSS 中嵌入的材料,而材料缺失这一状况由同一条强制规则处理。

B-LTA 文件时间戳由一张本身也会过期的 TSA 证书锚定。归档循环在该过期之前运行,为 TSA 证书链收集新鲜的吊销材料,重写 DSS,可选地添加一个以 TSA 证书哈希为键的 VRI 条目,并在更新后的状态之上添加一个新的文件时间戳。每个新时间戳覆盖此前的各个时间戳。按计划运行该循环是一项运维义务;当循环在未配置 TSA 或处于 strict-offline 策略下被请求时,生产者会引发一个错误。完整的归档范围记录在归档深度参考

TypeKindRoleStabilitySince
SignerInterfaceinterface (NextPDF\Contracts)Core 签名契约stable1.0.0
LtvManagerInterfaceinterface (NextPDF\Contracts)在运行时解析的长期生产者 + 归档循环契约stable1.0.0
TsaClientInterfaceinterface生产者调用的 RFC 3161 TSA 客户端stable1.0.0
SignatureLevelenum (NextPDF\Security\Signature)B-B、B-T、B-LT、B-LTA 选择器与可用性探测stable1.0.0

SignatureLevel::requiresDss → 对 B-LT、B-LTA 为 true。requiresDocumentTimestamp → 仅对 B-LTA 为 true。requiresTimestamp → 对 B-T、B-LT、B-LTA 为 true。生产代码依赖这些契约;具体的 Enterprise 实现类是内部的,不属于公开 API。

ClaimStandardClause
签名/时间戳以 DER 编码存储在 /Contents 中。ISO 32000-2§12.8.1
LTV 使用一个 DSS 和一个文件时间戳字典。ISO 32000-2§12.8
DSS 是文档 catalog 中 DSS 键所对应的那个字典;持有 Certs、OCSPs、CRLs。ISO 32000-2§12.8.4.3
文件时间戳字典结构。ISO 32000-2§12.8.5
长期签名的 DSS + 文件时间戳。ETSI EN 319 142-2§5.5
处理器支持 DSS + 文件时间戳。ETSI EN 319 142-2§6.3.3.3
RFC 3161 请求返回 TSTInfo;genTime 为 UTC 创建时刻。RFC 3161§2.4.1, §2.4.2
OCSP good/revoked/unknown 由 thisUpdate/nextUpdate 限定。RFC 6960§2.2, §4.2
朝向信任锚的路径验证输入。RFC 5280§6.1

所有条款均为转述。NextPDF 不复述规范性文本。NextPDF 不作出任何 PAdES 认证声明: 生产者写出与 ETSI EN 319 142 所定义的 B-LT 和 B-LTA 级别相符的结构;不声称任何符合性测试结果或第三方背书。ETSI EN 319 142-1 基线级别部分不在所引用的证据集合之内,因此所引用的 ETSI 锚点是 EN 319 142-2,而 ISO/RFC 锚点承载长期与时间戳的主张——与 Core 签名参考相同的披露态势。一个产出的签名是否能验证,是验证者依据其信任锚与吊销新鲜度策略所作的决定;生产者嵌入材料,并不断言任何受信任的结果。

  • DSS 必须在文件时间戳之前写入;在 DSS 之前写入的时间戳并不覆盖验证材料。
  • strict 强制(默认)在非根证书缺失吊销材料时引发一个错误。permissive 需主动启用。
  • 未配置 TSA 的 B-LTA 会引发一个错误,而非产出 B-LT。
  • strict-offline 策略:不进行任何 OCSP/CRL/TSA 网络访问;strict-offline 下无法达到 B-LTA。
  • 文件时间戳 token 有一段受限的预留空间;超出该空间的 token 会引发一个错误,而非被截断。

FIPS 140-3 密码学策略配置文件是一项 Enterprise 能力,与安全模块一同记录。长期生产者仅加入用于文件时间戳的 SHA-256 摘要与 RFC 3161 交互;签名原语来自 Core 签名器。在 FIPS 配置文件下,会产出相同的 DSS、VRI 与文件时间戳结构;约束适用于签名与摘要算法,而不适用于 DSS 布局。通过 PKCS#11 进行的硬件密钥保管与安全模块一同记录,不在本页范围之内。

  • Core 产出 B-B 与 B-T(B-T 对签名值加上 RFC 3161 时间戳)。Pro 通过同一套 Core 栈产出 B-B 与 B-T。B-LT 与 B-LTA 仅由 Enterprise 产出。
  • 生产者写入 DSS(B-LT)以及覆盖 DSS 的文件时间戳(B-LTA)。它嵌入验证材料;它不断言任何受信任的验证结果。
  • 失败关闭的吊销强制默认值在非根证书缺失吊销材料时引发一个错误,除非调用方主动选择 permissive 工作流程。
  • B-LTA 需要一个已配置的 TSA;若没有,B-LTA 步骤会引发一个错误,而非降级为 B-LT。

在仅有 Core 的部署中,软件签名器通过 SignerInterface 产出 PAdES B-BB-T;Core 附带 RFC 3161 时间戳路径,因此 B-T 不需要 premium 包。Core 没有 DSS、VRI 或文件时间戳生产者;一个 B-LT 或 B-LTA 请求会因 SignatureLevel::isAvailableInEnvironment 返回 false 而失败关闭。

在仅有 Pro 的部署中,签名路径是 B-B/B-T 基线加上远程与云 KMS 签名工作流程。Pro 不产出任何 DSS 或文件时间戳。RemoteSigningConfig 携带 Core 的 SignatureLevel 枚举,但长期级别(B-LT/B-LTA)是一个 Pro 不予处理的前置声明值;长期生产者在运行时通过 Core 契约解析,并在 nextpdf/enterprise 中提供。

内部机制细节留在源代码仓库的内部文档中,不在本手册范围之内。

NextPDF Enterprise 嵌入验证材料;它与调用方提供的 OCSP/CRL 响应器和一个 RFC 3161 TSA 集成。它不运营、不托管,也不保证这些响应器或 TSA 的可用性。长期有效性取决于响应器、TSA、归档循环计划,以及运营方——而不是仅取决于 NextPDF Enterprise。 运营方负责 TSA 选择与可达性、吊销响应器访问或预先收集的材料、网络策略,以及在每张时间戳证书过期之前运行归档循环。

本页仅记录可外部观察的行为与受支持的公开 API 范围。内部命名空间路径、辅助类、机制表、runbook 文件名与工单前缀不在范围之内。

与 ETSI EN 319 142 所定义的 B-LT 和 B-LTA 结构相符是一项结构性陈述,不是法律意见,也不是认证。NextPDF 不作出任何 PAdES 认证声明。 一个产出的签名是否能验证,是验证者依据其信任锚与吊销新鲜度策略所作的决定。