量子计算的第二个威胁
说到后量子密码学，大多数人脑海中浮现的场景是这样的：量子计算机到来之后，今天加密传输的数据将被解密。针对这一威胁，互联网已经在行动——Cloudflare 的数据显示，目前约有 50% 流向其边缘网络的流量，已经受到后量子加密的保护，能够抵御"今日截获、未来解密"这类攻击。
但加密只是硬币的一面。量子计算还有第二个威胁：破解服务器的 TLS 证书。一旦攻击者能够伪造合法证书，就可以冒充任意服务器，对毫不知情的用户实施中间人攻击。
好消息是，我们已经有了可用于量子安全认证的后量子算法。坏消息是，在 TLS 中推广这些算法，需要对互联网上最复杂、最关键的安全系统之一——Web 公钥基础设施（WebPKI）——做出重大改变。
核心矛盾：后量子签名太"胖"了
问题的根源在于算法本身的体积。
ML-DSA-44 是 NIST 标准化的性能最好的后量子算法之一，它的签名长度为 2420 字节，而目前最流行的非后量子签名算法 ECDSA-P256 的签名仅有 64 字节；ML-DSA-44 的公钥为 1312 字节，ECDSA 的公钥同样只有 64 字节。这意味着大约 20 倍的体积增长。
如果 TLS 握手中有多个公钥和签名，叠加起来就是数十 KB 的额外开销，足以对 TLS 的性能产生明显影响。
这就形成了一个两难困境：直接替换成后量子证书，在量子计算机出现之前没有任何安全收益，却会立刻带来性能损耗，很难说服所有人默认开启；但坐等威胁临近再迁移，风险同样巨大——迁移总是比预期花费更长的时间，我们不能拿互联网的安全和隐私去赌。
出路只有一条：找到一种方式，让后量子证书足够轻量，可以今天就默认为所有人开启。
先搞清楚：TLS 握手里到底有多少签名？
要理解 Merkle Tree Certificates 解决的是什么问题，需要先数清楚现有的 TLS 握手里究竟携带了多少密码学材料。
基础认证：信任的传递
当浏览器连接一个网站时，需要验证服务器身份。服务器用自己的私钥对握手消息签名，客户端用服务器的公钥验证签名，以此确认双方对话的真实性。
如果客户端已经预先知道服务器的公钥，那么只需要 1 个签名就能完成认证。但现实中互联网上大约有 10 亿台 TLS 服务器，不可能给每个客户端预装所有服务器的公钥。
解决方案是证书：CA（证书颁发机构）用自己的私钥为服务器的公钥签名背书，客户端只需预装几百个 CA 的公钥，而不是数十亿个服务器公钥。
这带来了 +1 个签名、+1 个公钥，合计：2 个签名，1 个公钥。
中间证书：更长的信任链
随着 WebPKI 的演进，信任链变得更长了。现在通常一条证书链包含两张或更多证书，而不只是一张。原因是 CA 有时需要轮换密钥，在新密钥被所有客户端信任之前，需要用旧密钥为新密钥签发一张过渡证书，附在证书链末尾。
这又带来了 +1 个签名、+1 个公钥，合计：3 个签名，2 个公钥。
证书透明度：再加两个签名
证书透明度（CT）要求每张证书在被浏览器信任之前，必须被记录到至少两个公开日志中。日志在收到证书后会立即返回一个签名（SCT），证明其已承诺将该证书纳入日志。
这又带来了 +2 个签名，合计：5 个签名，2 个公钥。
这就是当前互联网上一次典型 TLS 握手的密码学开销。在使用 64 字节签名的 ECDSA 时代，5 个签名不是大问题。但换成 2420 字节的 ML-DSA 签名，光签名就超过 12 KB，性能影响不可忽视。
Merkle Tree Certificates：把签名压缩到极限
Merkle Tree Certificates（MTC）是 WebPKI 下一代设计提案，其核心目标是：将 TLS 握手中所需的公钥和签名数量削减到绝对最小值。其目标效果是：1 个签名、1 个公钥、1 个 Merkle 树包含证明。
这是怎么做到的？
批量签名：一次签名覆盖一批证书
普通 CA 对每张证书单独签名。Merkle Tree CA（MTCA）的做法完全不同——它批量发证，对一批证书统一签名一次。
具体机制是 Merkle 树：把这批证书排列成树的叶子节点，每个内部节点的值等于其两个子节点的哈希值，树根（Tree Head）再用 MTCA 的私钥签名。
这棵树的结构保证了批次中每张证书都经过了 MTCA 的签名：如果尝试篡改任何一张证书的任意一个比特，树根的值就会改变，签名验证就会失败。
包含证明：代替签名放进证书
每张 MTC 证书本身不携带签名。取而代之的是一份包含证明（Inclusion Proof）——从该证书（叶子节点）到树根路径上，每个兄弟节点的哈希值序列。
给定一个经过验证的树根，这一组哈希值就足以证明该证书确实被包含在这棵树中。
带外分发树头：TLS 握手不再需要 CA 签名
关键问题是：客户端如何获得已签名的树根？答案是带外分发——树根由浏览器厂商（如 Chrome）定期推送给客户端，不需要在每次 TLS 握手中传输。
整个验证流程变成了：
- 客户端在 TLS 握手开始时，告诉服务器自己持有哪些树头；
- 如果服务器持有一张被客户端已知树头覆盖的 MTC，就直接用这张证书完成认证；
- 客户端本地用持有的树头验证包含证明，无需在握手中传输 CA 签名。
结果：原来需要 5 个签名的握手，变成了 1 个签名（服务器自己的）+ 1 个公钥 + 1 个包含证明。即便使用后量子算法，这个体积也相当小。
更完整的设计细节
地标（Landmark）：周期性快照
MTC 并不为每个批次单独建一棵树，而是维护一棵持续增长的大树，以实现更好的透明性。随着树的增长，周期性地选取子树头作为"地标"，推送给浏览器。
快速路径与降级路径
MTC 的高效依赖于客户端地标足够新。如果客户端的地标过期（预期证书有效期约为一周），服务端需要回退到体积更大的备用证书。服务器会同时准备两类 MTC：常规情况用小体积的普通 MTC，降级情况用可立即颁发、无需地标验证的备用 MTC——后者体积更大，但至少能保证服务正常。
CT 透明度内建
MTC 规范将证书透明度作为 PKI 的一等功能，让每个 CA 运营自己颁发证书的专属日志。透明度不再是事后补充的外挂机制，而是从设计层面内置到证书生命周期中——这也消除了原本 CT 带来的额外 2 个签名开销。
实验部署：如何在不动信任根的前提下测试
理论再漂亮，也需要在真实网络中验证。Cloudflare 与 Chrome 宣布将对 MTC 进行实验性部署。
一个棘手的鸡蛋问题
成立一个新的 CA 通常需要数年才能被主流浏览器信任。Cloudflare 没有打算成为一个"真正的" CA，Chrome 也不会直接信任 Cloudflare。
为了在合理的时间框架内推进，同时不牺牲必要的尽职调查，计划"模拟"MTCA 的角色：运行一个 MTCA（基于 Workers 和 Cloudflare 的 StaticCT 日志），但对于颁发的每一张 MTC，同时发布一张来自现有受信 CA 的证书，且两者内容相互一致。这张配对证书被称为"引导证书"（Bootstrap Certificate）。
当 Chrome 的基础设施从 MTCA 日志拉取更新时，同时拉取这些引导证书并验证两者是否一致。只有一致时，才将对应的地标推送给 Chrome 客户端。
换句话说，Cloudflare 实际上是在将一张现有 CA 颁发的合法证书"重新编码"为 MTC 格式，而 Chrome 利用证书透明度机制来确保 Cloudflare 诚实行事。整个实验过程中，信任根没有发生任何变化，对不参与实验的用户不产生任何影响。
实验希望回答的三个问题
哪些实现会出错？
协议僵化（Protocol Ossification）是部署协议变更时永远存在的问题——那些不经常使用的灵活性，往往会因为实现错误或中间件问题而在实际部署时折戟。TLS 1.3 的部署就因此比预期晚了数年。早期测试是发现并修复这类问题的唯一有效手段。
性能能否真正提升？
预期 MTC 将减少握手体积，甚至比今天的非后量子证书更小。ML-DSA 的签名验证速度与 ECDSA 相当，而需要验证的签名数量大幅减少，预计会带来延迟的实际下降。实验数据将验证这一预期是否成立。
多少客户端能保持足够新？
MTC 的性能收益需要客户端和服务端大致保持同步。预计 MTC 有效期约为一周，如果客户端的最新地标已经超过一周，服务器就需要回退到体积更大的备用证书。了解回退发生的频率，将帮助团队调整协议参数，减少降级概率。
总结
这篇博客所呈现的问题和方案，是后量子迁移中最深层的那道难题：加密的量子安全可以用"升级算法"来解决，但认证的量子安全需要重新设计整个 PKI 的信任模型和数据结构。
MTC 的核心洞见是：通过将信息以聪明的方式重新排列，可以大幅减少所需签名的数量。把 CA 的签名从每次 TLS 握手中抽离出来，改为带外分发、离线验证，再用 Merkle 树的包含证明在握手中替代签名——这一系列设计让原本需要 5 个签名的握手压缩到 1 个，即便使用 20 倍体积的后量子签名，总开销也控制在了可接受的范围内。
这个实验真正有价值的地方，在于它把一个 IETF 草案从纸面推进到了真实流量的测试，并且在不改变任何现有信任关系的前提下完成了这一步。互联网协议的演进，就是在这样一次次谨慎而坚定的实验中发生的。
如果你对 MTC 的技术细节感兴趣，可以访问 IETF PLANTS 工作组的邮件列表，或直接查阅草案文档 draft-davidben-tls-merkle-tree-certs。
参考来源：Cloudflare Blog — "Keeping the Internet fast and secure: introducing Merkle Tree Certificates"
