时间戳与可信时间

Spec Spec: RFC 3161 RFC 3161 Spec Spec: RFC 5816 RFC 5816 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 Evidence § Standard-backed Evidence: Standard-backed

快速概覽

时间戳并不记录「这是何时签署的」。它证明的是更狭义、也更有力的事情：某一份特定数据在某个特定时刻之前就已存在，且这一点由签署者之外的第三方佐证。这个区别正是可信时间的全部价值所在，却也经常被误解。

为什么这很重要

签名内部的签署时间，只是签署者电脑声明的某个值。时钟可能因意外或蓄意操作而出错。如果何时的唯一证据只是签署者自己的主张，那么签署者就能随意把文件标成更早或更晚的日期。一张昨天才被撤销的证书，可以被伪装成仿佛去年就已签署。「何时」并不是细枝末节。它决定了使用现已过期或现已撤销的证书所生成的签名是否仍然有效。而一旦可信时间有误，建立在其上的每一项长期有效性论证都会随之崩溃。

精简版说明

• 签署者自己的签署时间是一项主张，而非证明。它很容易被伪造。
• RFC 3161 时间戳是来自时间戳机构（TSA）的已签名令牌，将你数据的哈希值绑定到 TSA 的时间。
• 它所证明的内容很精确：该数据在 TSA 所载明的时间之前就已存在。这并不是确切的创建时刻，而是一个上界。
• 该令牌会回显你的 nonce（随机数）与你的消息印记，因此它不可能是重放，也不可能对应到其他数据。
• 文件时间戳将同样的机制应用到整份 PDF，把其覆盖的所有内容——签名及其内嵌的验证证据——锚定到一个可信的时刻。

NextPDF 的处理方式

NextPDF 将时间戳视为需要验证的对象，而不只是需要获取的对象。请求一个令牌，只是工作中相对次要的一半。引擎的立场是：未经验证的令牌不构成证据。

当引擎为一个签名加上时间戳时，它会向 TSA 发送数据的哈希值与一个全新的随机 nonce，而绝不会发送数据本身。随后，返回的令牌会逐项比对使其具有意义的完整属性集：机构状态为「granted」、令牌中的 nonce 与送出的 nonce 相符、令牌中的消息印记与送出的哈希值相符、令牌本身的密码学签名通过验证、令牌的内容类型为时间戳类型，且所载明的时间落在可接受的容差范围内。任何不符都会构成带有分类原因的硬性失败。并不存在「看起来足够接近」的通融路径。文件时间戳遵循同样的规则，只是应用于整份文件，而非单个签名值。

1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

可信时间戳记如何取得、又证明了什么：将杂凑值加上一个 nonce 送给 TSA，TSA 回传一个将该杂凑值系结到其时间的已签署权杖，验证者在把它当成「数据在该时间之前已存在」的证明之前，会先确認此系结。

证据怎么说

Evidence § Standard-backed Evidence: Standard-backed 这个定义很精确。 Spec Spec: ISO/IEC 18014-2, §3 ISO/IEC 18014-2 §3 将时间戳记服务定义为一种提供*「某数据项在某个时间点之前就已存在」的证据*的服务——这是一个上界，而非创建时刻。 Spec Spec: ISO/IEC 18014-2, §7 ISO/IEC 18014-2 §7 定义了权杖的 TSTInfo 内容：一个消息印记（你数据的哈希值）、一个生成时间、一个序号，以及一个选用的 nonce。 Spec Spec: ISO/IEC 18014-2, §6 ISO/IEC 18014-2 §6 载明了验证者在验证成功时可以得出的结论：该数据项在令牌中的时间之前就已存在——不多也不少。

就 PDF 而言， Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 规定了文件时间戳记：位元组范围涵盖整份文件，但排除 Contents 值；该哈希值会发送给一个时间戳机构，返回的 RFC 3161 权杖——按 Spec Spec: RFC 5816 RFC 5816 所更新——会被放入 Contents。这与签名采用相同的字节范围规则，只是应用于时间而非身份。而 Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 正说明了为什么这对长期有效性如此重要：可信时间正是让验证器得以证明某个签名在其生成当日是可靠的依据——即使在证书过期之后亦然。

NextPDF 的引擎会送出哈希值与一个 nonce，而绝不送出数据；在把返回的令牌当成证据之前，它会逐项比对状态、nonce、消息印记、令牌签名、内容类型与时间容差。

Human-factors note: Human-factors note

本页开门见山地给出精确主张——时间戳证明数据由第三方佐证、在某个时间之前已存在——因为这里最常见、也最代价高昂的错误，就是把它夸大成「确切签署时刻的证明」。先陈述真实且更狭义的主张，是为了防止误用，并把这条警示放在机制说明之前。

实践示例

你不会亲手组装一个时间戳令牌。真正重要的是信任边界。TSA 是你需要配置并保护的对象，因为它的时间会成为你的证据。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

值得留意的边界在于：引擎送出的是哈希值，而非文件，因此 TSA 永远看不到你的内容。而且它会验证响应。一个你无法验证身份的 TSA，并不是可信时间。它只不过是另一个时钟。

常见误解

陷阱在于把时间戳读成「这份文件正是在这一天的 14:32 签署的」。它并不是为签署事件计时的秒表。它证明的是数据不晚于 TSA 的时间就已存在，而这是由第三方设定的上界。创建时间可能是那之前的任何时刻。第二个陷阱是假设任何时间戳服务器都能给你可信时间。一个你无法验证其签名，或其证书颁发机构并不受你信任的令牌，什么都证明不了。它是一个你没有理由相信的时钟。可信时间来自一个你能验证身份的 TSA，以及一个你已验证过的令牌，而不是来自向服务器索取一个数字这个动作本身。

限制与边界

NextPDF 会构建请求、只送出哈希值，并验证返回的令牌。它并不为其背后的证书颁发机构背书。TSA 的准确度、它自身证书的有效性，以及它的可信度，都是该服务与你部署配置的属性，而非引擎的属性。时间戳将一个哈希值绑定到一个时间。它对数据的意义、签署者的身份，或签署者的证书是否有效，都一概不予置喙。那些属于另外的检查，涵盖于 正确验证签名。引擎无法把一个不可信的 TSA 变得可信。本页也并未主张时间戳具有任何特定的法律效力；那取决于 TSA 的状态与司法管辖区。可信时间如何被重复运用，以在数十年间保持签名可验证，这在 长期验证 中有说明。

时间戳记功能的版本层级供应情形：

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — 针对签名值，使用由部署提供的 TSA 验证过的 RFC 3161 时间戳。
Enterprise	○ 新增 B-LT 与 B-LTA 所使用的文件时间戳，用以锚定内嵌的验证证据，并驱动归档更新循环。

相关文件

• 长期验证 — 文件时间戳如何封存内嵌证据，并随时间更新。
• PAdES 基准配置文件 — 签名时间戳（B-T）与文件时间戳（B-LTA）在等级递进中各处于什么位置。
• 合格签名说明 — 合格时间戳在 eIDAS 信任全貌中的定位。

词汇表

• 时间戳（RFC 3161） — 来自 TSA 的已签名令牌，将一份数据的哈希值绑定到 TSA 的时间，证明该数据在该时间之前就已存在。
• 时间戳机构（TSA） — 签发时间戳令牌的可信服务。
• TSTInfo — 令牌的内容结构：消息印记、生成时间、序号，以及选用的 nonce。
• 消息印记 — 被加上时间戳的数据的哈希值，会在令牌中被回显。
• Nonce — 随请求一同送出、并在令牌中被回显的全新随机值，使响应不可能是重放。
• 文件时间戳 — 涵盖整份 PDF 的 RFC 3161 时间戳（按 RFC 5816 所更新），把签名及其证据锚定到一个可信的时刻。