摘要

  • ES-T 锚定签名在某个早期时点已经存在；ES-C 记录完整证书路径与撤销材料的引用；ES-X 保存或保护这些材料；ES-A 则要求在旧算法或旧时间戳失去可信度之前，再用更强的保护包住整条历史。
  • 长期有效不是一次性属性。它依赖精确的原始字节、实际的验证值、适用策略，以及赶在上一层仍可验证时完成的续签。

签名位还在，验证世界却会消失

数字签名看起来很耐久，因为比特可以无损复制。但支撑判断的环境会衰老：签名者证书到期，CA 不再保存旧 CRL，OCSP 服务停止，TSA 证书失效，算法被降级，归档迁移还可能改变真正参与签名的字节。

2001 年 9 月以 Informational 发布的 RFC 3126，正面处理了这种时间错位。它承接 RFC 3125 的签名策略，并把 CMS、ESS、X.509 证书、撤销证据与可信时间戳编进一条长期验证路径。需要保存的并不只是 signature value，而是当初为何判定它有效的上下文。

ES-T 证明“当时已有”，不证明“内容为真”

基础 ES 包含数字签名与签名者提供的资料；ES-T 再加入针对签名的时间戳。若签名者没有提供，验证者必须在首次收到时生成，或保留接近首次验证时刻的安全时间记录。

RFC 3161 把这一证明限定得很窄：TSA 对 message imprint 签名，表示某份数据在特定时间已经存在。它甚至不必查看底层文件。因此，时间戳不证明陈述真实，不证明签名者有业务权限，也不证明交易已经完成。

但这个窄证明能划出先后次序。若签名密钥后来被盗，事前取得的时间戳可以支持“这份签名早于泄露”的主张。问题只是转移到了 TSA：它同样有证书、策略、算法与有限寿命。

ES-C 在远端服务忘记之前保存验证配方

ES-C 建立在 ES-T 上，加入完整证书路径与撤销信息的引用。未来的验证者因此能识别当初使用了哪些证书、CRL 或在线状态响应。

这些材料未必在签署瞬间齐全。RFC 3126 明确承认，撤销信息可能需要等待，临时 suspension 也可能要等到结果确定。长期证据不是签名函数一次吐出的成品，而是一段随后完成的采集过程。

引用还不等于值。仓库 URL 或对象标识无法阻止远端内容消失。RFC 3126 用 X-Long 单独容纳实际证书与撤销值，清楚地区分了“知道去哪里找”和“材料已经在手”。

OCSP 回答同样有边界。RFC 2560 的 good、revoked、unknown 都属于某个时点的状态证据。good 并不自动证明证书的其他条件、签名者权限或合同结果。

ES-X 为“证据本身”留下时间边界

ES-X 同时处理可得性与后来泄露。X-Long 收进 ES-C 所引用的完整值；X-Time-Stamp Type 1 对整个 ES-C 加时间戳，Type 2 则保护证书与撤销引用，两者还可以组合。

其历史价值在于排序。假设 CA 密钥多年后被攻破，争议发生时才拿出的证书链，不能单独说明它在攻破前就存在。若验证材料早已被可信时间戳覆盖，就能在适用策略下支持这种先后关系。

新层并不会修复旧层的错误。原文丢失、证书路径选错，或者直到泄露之后才加戳，再复杂的格式也只能把缺陷保存得更精致。

ES-A 把归档变成一项有截止日的工作

ES-A 面对的是保护机制自身老化。趁算法、密钥或旧时间戳证书尚未变弱，归档者要把签名数据、ES-C 与相关 ES-X 材料再次加戳，并尽可能采用更强算法或更长密钥。每当上一层保护接近失效，就可以再次续签。

归档时间戳覆盖原始内容、signed attributes、签名、早期时间戳、证书与撤销引用、已保存的实际值、可选 ES-X 时间戳，以及此前所有归档时间戳。它是一条密码学保管链，而不是孤立印章。

续签必须及时。若 hash 已能伪造，TSA 私钥泄露而没有可靠时间边界，或实际验证值已经丢失，一个新时间戳只能证明“现在存在这个残缺包”，不能恢复过去。后来 RFC 4998 在通用 evidence record 中进一步区分普通时间戳续期与重新 hash 的续期。

精确字节也是历史材料

RFC 3126 要求每次验证都能重现同一个 OCTET STRING。归档迁移因此不是单纯存储操作：换行规范化、字符编码转换、detached content 丢失，或重新导出一份外观相同的文件，都可能破坏签名输入。

真正需要长期保存的是一个组合包：精确字节、签名与属性、适用策略、证书路径、带时间的撤销材料、时间戳、实际验证值，以及历次归档续签。若只留下可阅读文件和数据库里的“valid”，未来便无法复演判断。

RFC 5126 后来取代 RFC 3126，并延续 CAdES-T、CAdES-C、CAdES-X、CAdES-A 家族。它证明这套分层设计继续存在，却不能倒推出 2001 年已经广泛部署。

长期签名其实是一套持续运作的制度

签名者控制原始动作；验证者控制首次验证与材料采集；CA、CRL 与 OCSP 提供有时效边界的证据；TSA 为 hash 标注时间；归档者保存精确内容并负责续签；日后的仲裁者再依据策略与外部法律或契约判断。

RFC 3126 的历史贡献，不是声称时间戳能让签名永生，而是把耐久性写成操作纪律：保存首次验证者知道什么，收进远端服务可能忘掉什么，为这些材料建立早于未来泄露的时间边界，并在旧假设坍塌前完成更新。长期证据必须不断移动，才能比原密钥活得更久。

来源

  1. https://www.rfc-editor.org/rfc/rfc3126.txt
  2. https://www.rfc-editor.org/info/rfc3126
  3. https://datatracker.ietf.org/doc/rfc3126/
  4. https://www.rfc-editor.org/rfc/rfc3125.txt
  5. https://www.rfc-editor.org/rfc/rfc3161.txt
  6. https://www.rfc-editor.org/rfc/rfc2630.txt
  7. https://www.rfc-editor.org/rfc/rfc2634.txt
  8. https://www.rfc-editor.org/rfc/rfc2459.txt
  9. https://www.rfc-editor.org/rfc/rfc2560.txt
  10. https://www.rfc-editor.org/rfc/rfc4998.txt
  11. https://www.rfc-editor.org/rfc/rfc5126.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt