利用 Merkle Tree Certificates 构建后量子证书颁发机构

当你在浏览器中输入一个地址时，如何确认你访问的是正确的网站？Web 公钥基础设施（Web PKI）是由策略、协议和基础设施运营商构成的复杂分布式生态系统，帮助你相信自己没有被引导至错误或恶意的网站。过去几十年里，这一生态系统经历了深刻变革。其中之一是透明度的引入：如今已强制要求所有证书记录在公开的证书透明度日志中。现在，它又面临新的挑战：量子计算机的到来已迫在眉睫，促使我们加快推进，在 2029 年前完成向后量子（PQ）密码学的升级。

这一过渡并不简单：仅仅将后量子密码学套用到互联网规模的证书上，将导致无法接受的性能下降。这一时刻呼唤 Web PKI 的全新方案——将透明度作为一等属性而非附加功能，设计出能夠高效扩展后量子签名的新系统。

在获得业界广泛支持后，Merkle Tree Certificates（MTC）已成为前进的方向。今年，在与 Chrome 完成成功的实验性部署后，Cloudflare 正全力推进 MTC 的落地。

随着今天 Cloudflare 宣布成为证书颁发机构 (CA)，我们很高兴地宣布，该 CA 将支持 MTC 颁发，目标是在 2027 年初纳入 Chrome 新推出的抗量子根证书库。秉持帮助构建更好互联网的使命，以及 Cloudflare 免费提供最强加密算法的一贯传统，我们将免费提供标准 MTC 颁发服务。拥有一个同时支持传统证书和 MTC 颁发的 CA，使我们能够默认采用最安全的可用身份验证方式，为互联网的大部分提供顺畅、高性能的 PQ 升级路径。

当前的信任生态系统

为了理解 MTC 如何改变游戏规则，让我们先了解一下当今网络中信任的运作方式。

在客户端，浏览器——在此语境中称为“TLS 客户端”——维护根证书计划，规定 CA 必须遵守的一套策略才能获得信任。在服务器端，CA 是受信任的把关人：它们运营证书颁发基础设施，验证域名所有权，并证明域名与该域名所有权的公钥之间的绑定关系。

但我们如何核实 CA 是否遵守规则？这就引出了证书透明度（CT）——它使证书颁发过程可以被公开审计。CA 颁发证书时，还必须将该证书提交至至少两个公开日志。Cloudflare 自 2016 年起运营 Nimbus CT 日志家族，并正在推出新的静态 CT 日志家族 Raio。

CT 生态系统让证书可以被公开查看，但这并不意味着它们被正确颁发或可以安全使用。监控通过将这些日志记录与域名所有者的预期进行比对并报告可疑活动来提供帮助。Cloudflare 于 2019 年推出了证书透明度监控，并于近期实现了正式上线。我们还在 Radar（前身为 Merkle Town）的证书透明度页面发布关于证书的大规模统计数据。

随着各组织开始将服务器升级以使用 PQ 身份验证，证书透明度监控将在检测潜在后量子降级攻击中发挥更加重要的作用。已将域名升级至后量子身份验证的域名所有者应监控 CT 日志中意外核发的传统证书，以防止客户端落入恶意降级路径。

当前系统的部分问题在于透明度是后期追加的，因而衍生扩展性瓶颈。证书往往在多个日志中以不同形式被多次记录，要求监控方下载并处理每个日志以免遗漏颁发记录。这代价高昂，使得在互联网规模上激励多元化的日志运营商更加困难。据我们估算，PQ 签名将使 CT 日志需要存储的数据量膨胀 40 倍。这一扩展性挑战及其背后的激励机制失衡，正是后量子扩展性问题的核心所在。

后量子扩展性问题

我们已就后量子密码学扩展的挑战进行了深入探讨，简而言之：要在互联网规模上支持服务器身份验证，Web PKI 必须在不向每个客户端预先加载每台服务器公钥的情况下，对约十亿台 TLS 服务器进行身份验证。传统上，CA 通过使用证书链作为信任分发机制来解决这个问题。然而随着时间推移，密钥和证书透明度等附加内容增加了更多的公钥和签名——典型的 TLS 握手需要五个签名和两个密钥。PQ 签名约是传统签名的 40 倍大，在规模上对客户端、CA、日志和监控方而言将产生难以承受的额外负担。

Merkle Tree Certificates (MTC) 由此登场。这是 IETF PLANTS 工作组的草案规范，描述了一种面向紧凑、高效、后量子证书的架构。MTC 将证书批量放入仅追加的 Merkle 树，CA 只需对树的根签名而无需对大量单独证书签名。浏览器或其他客户端可透过紧凑的包含证明——一系列密码哈希——对签名树头进行验证，而无需逐一验证每张证书。MTC 背后的核心理念是“不要记录你颁发的内容，而是通过记录来颁发”。将颁发与记录相结合，透明度便成为运营的必要条件而非附加功能。

重新设计的 PKI 中证书颁发机构的角色

我们正将 MTC 颁发能力的建设作为创设 Cloudflare CA 的核心组成部分。这意味着在跟踪新的 PQ 根证书计划要求的同时，还要在构建传统 CA 的设施、运营和合规功能的同时，开发颁发和镜像软件堆栈，任务不可谓不艰巨！

好处在于，我们可以从第一天起就优先考虑这一新后量子 PKI 的需求与架构，以符合 Cloudflare 价值观和全球网络的方式建立我们的体系，并在这段新旅程中尽可能保持透明。

让我们来看看为 MTC 更新后的架构：

与传统的 CA 生态系统相比，你会发现 CA 的职责大体相同：验证对域名的控制权、将其与公钥绑定、颁发证书。主要区别在于，在 MTC 生态系统中，CA 不再直接对证书签名再记录，而是维护一个由 Merkle 树支撑的透明度日志，证明证书确实在树中的包含证明充当信任锚。CA 还将运营镜像共同签名者，存储颁发日志的副本，验证其仅追加的一致性，并确保这些日志对更广泛生态系统的透明度和可用性。

颁发 MTC

MTC 有两种形式，两者都可以编码为当今客户端软件能识别的 X.509 证书格式——只是使用了“特殊”的签名算法。在独立形式中，证书的签名值包含颁发日志的共同签名树头以及包含证明（一系列哈希值），证明该证书包含在该日志中。如果客户端能够以带外方式取得共同签名树头（例如通过浏览器更新机制），证书可改以相对 landmark 形式提供，此时签名值仅包含轻量包含证明，完全不含繁重的后量子签名。

为便于理解，让我们看一个独立证书颁发的示例。当网站需要为其域名申请证书时，可通过 Automatic Certificate Management Environment（ACME）协议向 CA 提出请求，该协议处理证书请求、域控验证和颁发流程。Cloudflare 的 ACME 基础设施将是 Boulder 的分支版本，Boulder 是驱动 Let’s Encrypt 的广泛部署且久经验证的 ACME 软件。Let’s Encrypt 正积极在 Boulder 中开发 MTC 支持，我们计划维护自己的分支，纳入这些上游变更以及 Cloudflare 特有的修改，并在可能的情况下向上游贡献代码。

当 MTC CA 收到证书颁发请求时，CA 的 ACME 服务器会核实服务器确实控制该域名。核实通过后，CA 将数据序列化并添加到仅追加日志中。

将 MTC 条目添加到颁发日志后，CA 计算日志的更新状态，然后对该状态签署检查点。该检查点证明 CA 已在该时间点之前颁发了日志 Merkle 树中包含的每一条目。

CA 随后将更新的日志状态和新检查点发送给受信任的共同签名者。共同签名者持久存储 CA 颁发日志的副本，并验证每个新状态是否仅追加、与之前的树保持一致且格式正确。这一额外的共同签名让客户端和监控方确信另一个受信任的方已观察到相同的日志状态，并验证了 CA 没有向生态系统的不同部分呈现不同的颁发视图。它还确保了即使 CA 颁发日志不可用，颁发的证书也可用于监控。

Chrome 的抗量子根证书计划草案策略要求至少两个共同签名：一个来自由独立组织运营的 Chrome 认可镜像共同签名者，一个来自颁发 MTC 的 CA 本身。因此，我们将为其他试点 CA 运营镜像，并要求我们自己颁发的证书至少获得一个独立的共同签名。

Cloudflare 将在 Azul（我们的开源 Rust 透明度日志）中实现镜像共同签名者，并为实现最大互操作性，实现 c2sp 的 tlog 镜像协议。

最终，在成功从镜像共同签名者处获得共同签名后，CA 用共同签名、服务器公钥和包含证明构建 MTC，并将其发送给服务器，服务器此后即可将其用于 TLS。

高效分发 PQ 签名：landmark 优化

虽然独立证书可以正常工作，但它们在 TLS 握手过程中仍需传输大量 PQ 签名，限制了效率。MTC 设计带来的真正性能提升来自相对 landmark 证书。

CA 不必在每张证书中发送共同签名，而是可以将覆盖日志中所有活跃证书的子树序列指定为 landmark，并通过带外更新服务将这些子树（及用于验证它们的数据）分发给客户端。在 TLS 握手期间，对服务器的实际身份验证通过浏览器检查服务器的证书数据——包括其域名和公钥——是否出现在 CA 日志的受信任子树中来完成。如果包含证明将该证书与经过共同签名的 landmark 相连接，并且公钥在 TLS 握手期间证明了所有权，客户端便确认自己正在与正确的服务器通信。

通过定期以带外方式将这些签名和树元数据传输给 TLS 客户端，少量的 MTC 批次签名就能高效覆盖特定 CA 颁发的数十亿张证书。虽然 landmark 在规模上更高效，但并不能消除对独立 MTC 的需求——客户端可能是新安装的、处于离线状态，或缺少相关的 landmark 更新。因此，服务器保留独立证书作为回退方案至关重要。

MTC 的实战表现：与 Chrome 实验的结果

今年，我们与 Chrome 进行了一次实验，测试客户端和服务器之间 MTC 的可行性。我们运营了一个“引导 CA”（模拟颁发流程的虚假 CA），为 Cloudflare“免费”套餐中部分 Cloudflare 域名颁发了由传统证书链支持的 MTC，并向 Chrome Beta 146 的 50% 用户提供服务。实验期间，我们成功提供了数十亿张 MTC。

对于 TLS，我们发现常见情况相当高效：使用相对 landmark 证书时，握手只需传输一个公钥、一个签名以及不到 1 kB 的包含证明。在实验中，当无法与客户端协商相对 landmark 证书时，我们回退到传统证书链而非独立证书。在 CT 方面，MTC 也改变了透明度的扩展特性：日志只需保存公钥哈希；没有按条目的签名，树头上的签名涵盖整个日志。这防止了证书爆炸，因为 CA 颁发日志是 CA 所颁发的所有证书的唯一可信来源，日志使用者只需获取每张证书的单一副本。

结果：MTC 确实有效！以中位数计，使用相对 landmark MTC 比传统签名链快 9%（诚然，这一性能优势大部分来自中间证书的省略）。由于我们是用传统签名测试 MTC 的，预计采用后量子签名后改善幅度将更大。对这些结果以及 IETF PLANTS WG 中 MTC 跨行业合作水平感到满意，我们于上个月（2026 年 8 月）开始逐步结束实验。

MTC 的未来之路

我们很高兴，与 Chrome 的实验证明了 MTC 在实践中可以运作，更对能够以真正的 CA 身份颁发证书感到振奋。

然而，还有一些更宏观的问题，只能通过与整个 PKI 生态系统开展这场大规模实验来回答。独立监控方能否在生产规模下消费并验证 MTC 颁发日志？是否会出现多个 CA 与共同签名者，使系统获得韧性所需的多样性？浏览器应如何在紧凑 landmark MTC 的性能优势与缺少最新 landmark 的客户端所需的回退路径之间取得平衡？MTC 已成为后量子身份验证的权威设计，但要在生产互联网规模上加以验证，需要多元化的根证书计划、浏览器厂商、CA、镜像、监控方以及更广泛社区的参与。

我们将参与 Web PKI 下一阶段的机会视为荣耀，并认真对待运营 CA 基础设施的责任。CA 在信任生态系统中占据特殊地位——浏览器、域名所有者和普通用户都依赖它们正确验证身份、保护签名密钥、遵守策略并可靠运行。在 Cloudflare 的 CA 被浏览器信任以颁发 MTC 之前，我们需要向 Chrome 的 Quantum Resistant Root Store 提出申请并经过严格的评估流程。我们欢迎这种审查，并期望让自己达到其他任何被信任、承担保障互联网安全职责的 CA 的同等高标准。我们希望有更多 CA 涌现以支持 MTC 的采用，也期待与任何有意部署 MTC 的浏览器展开合作。