RFC 9162《证书透明度 2.0（Certificate Transparency v2.0）》中文导读

摘要

"Certificate Transparency aims to mitigate the problem of misissued certificates by providing append-only logs of issued certificates."（§1）

译：证书透明度旨在通过提供已签发证书的仅追加日志，来缓解证书误签发的问题。

RFC 9162 是证书透明度（CT）的 2.0 版本，废止了作为 CT 1.0 的 RFC 6962。它的核心思路不是阻止 CA 误签发，而是让任何误签发都无法被隐藏：所有证书都被写入公开、可审计、只能追加的日志，域名持有者与第三方监视者因此能够及时发现自己名下出现的可疑证书。

与邮件生态的关联：MTA-STS（RFC 8461）依赖公共 CA 体系校验 MX 主机证书，SMTP over TLS 的证书信任也建立在同一套 PKI 之上。CT 是这套 PKI 的问责基础设施——它决定了「有人为你的邮件域签发了一张流氓证书」这件事能否被发现。因此，理解 CT 对评估邮件传输加密的真实强度有直接意义。

2. 密码学组件

2.1 Merkle 树

日志以二叉 Merkle 树实现「仅追加（append-only）」性质。每个叶子节点是一条提交条目的哈希，内部节点由其子节点哈希拼接后再哈希得到。为防止叶子节点与内部节点被混淆构造（第二原像攻击），两类哈希各自带有域分离前缀：叶子用 0x00，内部节点用 0x01。

这一结构使两类证明可以高效生成与校验：

• 包含证明（inclusion proof）：证明「某条目确实在某棵树中」，代价为 O(log n)。
• 一致性证明（consistency proof）：证明「较新的树是较旧的树的追加扩展」，即历史条目未被删改。

2.2 签名

日志使用配置好的签名算法对树头等结构签名；算法与哈希函数均可由日志参数指定，配合第 9 节的算法敏捷性机制演进。

3. 提交者（Submitters）

任何实体都可以向日志提交证书链；CA 还可以提交预证书（precertificate），用于在正式签发前先行公示签发意图。提交时须附带直到受信任锚点的完整证书链。CA 对预证书的签名，被视为等同于对相应证书的签发承诺——误签发的责任同样成立。日志接受提交后返回 SCT。

4. 日志格式与运作

• 4.1 日志参数：包括 Base URL、哈希算法、签名算法、公钥、Log ID、最大合并延迟（MMD, Maximum Merge Delay）等。
• 4.2-4.3 评估提交与日志条目：日志须校验提交链的有效性，再将其转为日志条目。
• 4.4 Log ID：本版改用 OID 标识日志。
• 4.5 TransItem 结构：CT 2.0 引入的统一容器结构，SCT、STH、各类证明都以 TransItem 承载，取代了 1.0 中分散的多种结构。
• 4.8 SCT（Signed Certificate Timestamp，签名证书时间戳）：日志接受提交后返回的承诺凭据，包含 log_id、timestamp、扩展与签名，含义是「本日志承诺在 MMD 内把该条目并入树中」。
• 4.9-4.10 树头与 STH（Signed Tree Head，签名树头）：树头数据含 timestamp、tree_size、root_hash 与扩展；日志对其签名后即为 STH，用以证明某一时刻的树状态。

"Periodically, each log SHOULD sign its current tree head information (see Section 4.9) to produce an STH."（§4.10）

译：每个日志应当（SHOULD）周期性地对其当前树头信息签名，以生成一个 STH。

• 4.11-4.12 证明：定义包含证明与一致性证明的结构与校验流程。
• 4.13 关闭日志：日志停运须遵循规范流程——冻结、停止接收新提交、发布最终 STH，以便既有 SCT 仍可被验证。

5. 日志客户端消息（API）

第 5 节定义了一组 HTTP API，涵盖提交条目、获取最新 STH、获取一致性证明、按哈希或按索引获取包含证明、拉取条目区间、获取受信任锚点等。CT 2.0 把 1.0 中分散的提交接口统一为 submit-entry，并允许在获取包含证明的同时一并取得一致性证明，减少往返。

6-8. 各方角色

• 6. TLS 服务器：负责在握手中向客户端出示 SCT 等透明度信息。CT 2.0 将承载方式从 1.0 的 signed_certificate_timestamp TLS 扩展改为 transparency_info 扩展。
• 7. 证书颁发机构（CA）：负责生成预证书、提交日志、并把获得的 SCT 嵌入最终证书或通过其他通道分发。
• 8.1 TLS 客户端：校验所收到的 SCT 签名，并可依据本地策略要求「证书必须带有若干个来自受信日志的 SCT」。
• 8.2 监视者（Monitor）：必须检查所关注日志中的每一条新条目，可保存日志全量副本。典型工作循环是：周期性拉取 STH → 校验签名 → 拉取新条目 → 自行重算树哈希或校验一致性证明 → 发现自己关心的域名出现的证书，以及日志本身的异常行为。这是域名持有者发现流氓证书的主要途径。
• 8.3 审计（Auditing）：审计的目标是确认日志可达、遵守 MMD 与 STH 发布频率、保持仅追加性质，且不向不同观察者提供分叉视图。监视者通过校验 STH 之间的一致性证明来审计；TLS 客户端则可通过包含证明来核实自己拿到的 SCT 是否真的已被并入树中。

9. 算法敏捷性

CT 1.0 把哈希与签名算法写死，CT 2.0 改为通过 IANA 注册表管理可用算法，使日志能够在密码学演进时平滑迁移。

1.3 相对 CT 1.0（RFC 6962）的主要差异

• 算法敏捷性：哈希与签名算法可配置，由 IANA 注册表维护。
• 预证书改为 CMS 对象：不再是 X.509 证书，从而避开序列号唯一性冲突与「毒扩展」这类变通手法。

  "Precertificates are now CMS objects rather than X.509 certificates, which avoids violating the certificate serial number uniqueness requirement in Section 4.1.2.2 of [RFC5280]."（§1.3）

  译：预证书现改为 CMS 对象而非 X.509 证书，从而避免违反 RFC 5280 第 4.1.2.2 节关于证书序列号唯一性的要求。

• Log ID 改用 OID，不再使用公钥哈希。
• 引入 TransItem 统一结构，取代旧的 SCT 列表与 MerkleTreeLeaf 等结构。
• TLS 扩展更名：由 signed_certificate_timestamp 改为 transparency_info。
• API 精简：一致性证明可与包含证明同时获取；提交接口统一为 submit-entry。

10-11. IANA 与安全考量

IANA 侧建立了哈希/签名算法、日志扩展等相关注册表。安全考量强调：CT 提供的是事后可发现性，而非事前阻止能力；日志运营方的诚实性、监视者的实际运行覆盖度，以及客户端是否真正强制要求 SCT，共同决定了这套机制在现实中的有效性。需要留意的是，本文档的状态为实验性（Experimental），当前公共 CT 生态的大规模部署仍主要基于 RFC 6962 所定义的 1.0 版本。

参考链接

• RFC 9162 英文原文：https://www.rfc-editor.org/rfc/rfc9162.txt
• IETF Datatracker 页面：https://datatracker.ietf.org/doc/html/rfc9162
• CT 1.0（被废止）RFC 6962：https://www.rfc-editor.org/rfc/rfc6962
• X.509 证书与 CRL 规范 RFC 5280：https://www.rfc-editor.org/rfc/rfc5280
• MTA-STS RFC 8461：https://www.rfc-editor.org/rfc/rfc8461
• SMTP DANE RFC 7672：https://www.rfc-editor.org/rfc/rfc7672