后量子迁移带来的体积问题
攻击者已经在做一件事：先收集，后解密（Harvest Now, Decrypt Later）。今天囤积加密流量，等量子计算机成熟后再用 Shor 算法批量破解。这让迁移到后量子密码学（PQC）从"未来的事"变成了"现在的事"。
密钥交换一侧的迁移已经完成：主流浏览器默认启用 X25519+ML-KEM 混合密钥交换，保护的是传输数据。尚未解决的是认证一侧，即证书。其障碍不在密码学，而在工程约束。
先看单个签名的体积变化：
大了 38 倍。而一次 TLS 握手要传的远不止一个签名：服务器证书的签名、中间 CA 的签名、CA 的公钥、CT 日志的 SCT 签名……把它们统统换成后量子算法，握手会从今天的 1 KB 左右膨胀到 10 KB 以上。
这一体积的影响不是延迟增加，而是连通性下降。实测数据显示，握手体积突破该量级会导致约 5% 的连接失败，成因包括丢包、超时以及中间设备丢弃超长握手。一个使二十分之一用户无法建立连接的方案，无法用于保护其余用户。
Chrome 团队因此明确表示：不会将后量子 X.509 证书直接加入根仓库。在现有结构内扩容不可行，需要改变架构。
批量签名：一次签名覆盖整棵树
直接的思路是在 X.509 内容纳更大的签名，再设法压缩传输。Google 与 Cloudflare 推动的默克尔树证书（Merkle Tree Certificates，MTC）采用了另一条路径：
密码学一点没变——签名依然是 NIST 标准化的 ML-DSA。变的是架构：把"逐张证书签名"改成"对整批证书的默克尔树根签名一次"，并把验证材料的传输从握手内挪到握手外。
默克尔树是 1979 年 Ralph Merkle 提出的数据结构：把每张证书的哈希作为叶子，两两哈希向上聚合，直到唯一的树根（Tree Head）。CA 只需要对这个树根签名一次，整批证书的完整性就都被这一次签名覆盖了。
一批可包含数十万至数百万张证书，2,420 字节的后量子签名因此被均摊至接近于零。
那浏览器怎么确认"我手上这张证书确实在那棵已签名的树里"？答案是包含证明（Inclusion Proof）——沿着从叶子到树根的路径，提供每一层的兄弟哈希。验证者拿着自己的证书哈希，逐级与兄弟哈希合并重算，如果最终算出的根与已签名的树根一致，证明就成立。
下图为交互演示：点击任意叶子可查看其证明路径，点击「篡改」可观察根哈希失配的过程。
关键在于证明长度是 log₂(n) 而非 n：8 张证书要 3 个哈希，1,024 张要 10 个，100 万张也只要约 20 个。
这个量级差异来自二叉树本身的形状。从叶子往上走，每上升一层，这个节点所覆盖的证书数量就翻一倍； 因此树的高度只随证书总数的对数增长——证书数量翻一千倍，证明也只是多出十个哈希。 换句话说，验证成本对批次规模几乎不敏感，这正是「一次签名覆盖整批」得以成立的前提。
机制的核心即在于此：数百万张证书共享一次后量子签名，每张证书额外承载的验证数据仅为约二十个哈希。
持续追加的签发日志与 Landmark 检查点
一个常见误解是：CA 累积一批证书后建立一棵树，签名完成即启用下一棵。实际机制并非如此。
MTC 里每个 CA（准确地说是 MTCA，MTC Certification Authority）维护一棵持续追加的树（append-only）。签发一张证书，就是往这棵树上追加一个叶子。这个动作没有额外的"提交到日志"步骤——签发本身就是入树。
这里出现一个矛盾：树在持续生长，而签名必须针对一个确定不变的状态。解决办法是给这棵树拍快照—— 在某个时刻截取它的当前形态，对这个状态签名并固定下来，此后新增的证书归入下一次快照。
这个快照就是 Landmark 检查点。生态周期性地从持续生长的树上选定一个子树根，对其签名， 并通过带外渠道分发给浏览器。浏览器在后台更新中获取这批 Landmark，时间点在任何握手发生之前。
该设计的关键在于签名的传输被完全移出握手过程。浏览器已持有经过验证的树根，握手时服务器只需提供该证书位于树内的证明，而证明本身不含签名，仅为一组哈希。
TLS 握手中的证书形态协商
MTC 的证书有两种形态：
- Landmark-relative 证书（快形态）：只含证书公钥 + 一条到 Landmark 的包含证明，约 736 B，不含任何在线签名。
- Standalone 证书（兜底形态）：自带联合签名（cosignatures），可独立验证，体积较大。
服务器为同一把密钥同时准备好这几种形态，具体发哪种，由 TLS 1.3 的 trust_anchor_ids 扩展协商：浏览器在 ClientHello 里声明"这些 Landmark 我已经验证过了"，服务器据此挑最小的那个发出去。
对比两条路径可以看出 MTC 的设计取舍：快路径为常态，慢路径为兜底。当设备长期离线导致 Landmark 过期，或对端不支持 MTC 时，连接不会失败，而是回退到自带签名的较大证书，代价是体积和延迟增加，但可用性不受影响。
这也解释了另一项设计选择：MTC 证书的有效期仅约一周。landmark-relative 形态的有效性依赖客户端持有较新的 Landmark，短有效期可将回退率控制在可接受范围。附带效果是吊销机制得以简化：不续期即失效，主动吊销仅需覆盖密钥泄露等紧急场景。
对网站运营者而言，每周一次的续期由 ACME 自动完成，与当前的运维方式没有差异。
内建的证书透明度
今天的证书透明（CT）是一套外挂系统：CA 签发证书之后，需要另行把它提交到 CT 日志，日志返回 SCT 签名，这个签名再随握手一起传给浏览器。
MTC 将这一顺序反转。
三个直接收益：
- 不存在未记录的证书。当前体系下可能出现签发成功但日志提交失败的证书；在 MTC 中证书无法在树外存在，透明度从可选附加项变为签发的固有属性。
- 握手减少两个签名。SCT 不再需要随握手传输。
- 日志与 CA 一一对应。每个 CA 的日志仅包含自身签发的证书，消除了预证书、重复提交与生态层面的重复存储。
迁移路线与时间表
Google 给出的迁移计划分三阶段推进：先进行实验部署，再引导公共基础设施，最后建立独立的根仓库。X.509 将长期并行存在。
其中 2026 年 6 月的节点尤为关键：为超过 5 亿网站提供证书的 Let's Encrypt 宣布采用 MTC 路线，计划 2026 年底部署测试环境、2027 年投入生产。这一表态使 MTC 从提案进入实际部署阶段。
对网站运营者而言，短期内无需操作。 证书侧的迁移由 CA 与浏览器完成；已通过 ACME 自动续期的站点将在切换时保持无感。
术语速查
本领域缩写密集，下表可供随时查阅。
常见问题
参考资料
- Google · Public Key Infrastructure FAQ: What are MTCs?
- Google Security Blog · Cultivating a robust and efficient quantum-safe HTTPS
- Cloudflare Blog · Keeping the Internet fast and secure: introducing Merkle Tree Certificates
- IETF PLANTS WG · draft-ietf-plants-merkle-tree-certs
- Let's Encrypt · A Post-Quantum Future for Let's Encrypt