摘要

  • 处于 Draft 状态的 pull request 679 拟在 TLS Baseline Requirements 中允许 ML-DSA-44、ML-DSA-65 与 ML-DSA-87，并规范订户证书、CA 证书、CRL 和 OCSP 响应中的密钥与签名。
  • 提案说明，它不会强制任何根证书库信任 ML-DSA，也不会改变 Certificate Transparency 日志对 SCT 的签名算法；其需求说明却明确列出 SDK 客户端、嵌入式与 IoT 系统、企业中间件及使用系统信任库的应用。
  • SCWG 章程授权其处理互联网可访问服务器的 TLS 证书；但有表决权的 Certificate Consumer 资格以安全浏览 Web 的公众软件为条件，Certificate Issuer 资格也以证书被该类浏览器接受为条件。
  • 章程明确排除的是一类更窄的内部 PKI，而不是用一句话排除所有非浏览器 TLS。现有文字因此留下真实的解释边界，不能被任一侧截取一句话替代。
  • 截至 2026 年 9 月 2 日，SC-106 仍是开放的 Draft PR，并未出现在官方 ballot 状态页。2025 年东京会议纪要和 PR 评论记录的是分歧，不是集体决定。
  • 在共同配置规范前，应公布一份授权回执，分别列出目标依赖方、适用章程条款、表决与参与路径、共同不变量、根库与 CT 权限、运行证据、替代场所以及复审条件。

草案中的需求主体与章程中的表决主体

SC-106 最值得先看的不是算法编号，而是它为什么要存在。PR 认为，许多依赖方目前无法通过既有 X.509 公共信任基础设施获得实用的后量子认证路径。它没有使用模糊的“生态”一词，而是逐项列出基于 SDK 的服务客户端、嵌入式和 IoT 系统、企业中间件，以及依赖操作系统厂商管理之信任库的应用。

这些软件当然可能验证服务器证书，却不必然是浏览器。SCWG 章程对有表决权的 Certificate Consumer 采用更具体的资格：组织必须向公众提供用于安全浏览 Web 的软件，并公开其根库、更新和合规要求。有表决权的 Certificate Issuer 也要证明其证书会被该类成员制作的浏览器视为有效。

两个集合可以重叠，但不能默认为相同。浏览器厂商可能同时维护操作系统或密码库，证书颁发机构也可能深刻理解设备与企业部署。专业知识能提供证据、警告与设计能力，却不能自动回答谁授权谁为另一类软件设定共同约束。

Lu Heng 对“利益相关者”与“委托主体”的区分在这里提供了一条编辑边界：受影响、到场和懂技术，不等于获得代表权。SC-106 因而需要明确说明，它究竟是一项以 Web 为主、顺带惠及非 Web 的最低规则，一项由章程附属权限承载的配置工作，还是面向多类公共信任消费者的共同规范。

冻结 diff 规定了什么

在 eefc670… 这一冻结 commit 上，草案把 FIPS 204 规定的三组 ML-DSA 参数引入 BR，增加公钥编码校验、订户证书 Key Usage 以及精确的 AlgorithmIdentifier 编码要求。参数必须缺省，HashML-DSA 不得使用，只允许“pure” ML-DSA。

更有争议的部分是双向配对。ML-DSA Subject Public Key 只有在证书签名也是 ML-DSA 时才可使用；ML-DSA 证书或预证书签名也只能认证 ML-DSA 公钥。CRL 与 OCSP 响应不认证公钥，因此不受后一限制。

PR 前言同时划出几条权限线。通过草案并不会迫使根库接受 ML-DSA 层级；当下各根计划的政策仍由各自维护。SCT 的签名算法也由 CT 日志运营者控制。换言之，BR 可以允许 CA 生成某种证书，却不能替根库作信任决定，也不能替日志作承载决定，更不能替客户端选择路径。

这份分工值得保留。但它也提出一个应被量化的问题：被点名的 SDK 或设备，当前究竟被哪一层阻挡？是 CA 审计规则、根计划、证书工具链、路径构建、信任库发布、服务器配置还是协商机制？研究范围内没有公开清单、规模统计或可复现实验把这些需求统一到同一条“纯链”规则上。

编号不等于正式程序状态

GitHub 标题已经使用 SC-106，正文也把预期结果称作 ballot。可是在研究截止时，页面仍显示 Open 与 Draft，只有一个 commit，没有正式 review。SCWG 官方状态页的 Voting、IPR Review、Discussion、Draft / Under Consideration 与历史清单均未列出 SC-106。

因此，本文只把它称为 Draft pull request。公开材料尚不能证明正式讨论期、proposer 与 endorsers、投票窗口、票数、IPR 审查、最终维护指南或生效日期。

程序状态不能互相借权。作者提交文本，工作组启动特定版本的程序，两类成员投票，IPR 环节处理排除声明，最终指南在特定日期生效；随后 CA、根计划、CT 和客户端各自部署。把早期文件统称为“ballot”，会让第一步提前继承后面所有步骤的权威。

不可变 diff 仍然重要。它能证明 8 月 26 日所提的具体规则；若后续修改，它会成为历史版本，而不会冒充最终结论。

章程在活动范围上较宽，在投票来源上较窄

仅引用“浏览 Web”不足以得出越权结论。章程第一节授权 SCWG 为用于认证互联网可访问服务器的 TLS 服务器证书制定基准要求和可接受做法，也允许针对新兴在线安全威胁更新规则，以及开展与主要任务相关的附属活动。这一活动描述并未缩减为某一个浏览器产品。

反过来，仅引用“互联网可访问服务器”也不足以覆盖所有依赖方。谁能以消费者身份表决，由“供公众安全浏览 Web 的软件”定义。颁发者的投票资格也通过浏览器是否接受其证书来检验。能使用同一根库的全部软件，并不自动成为这一决策选区的一部分。

Out of Scope 条款又增加一层。它排除企业仅为内部用途运行、且根未被任何 Certificate Consumer 分发的 PKI，并排除代码签名、S/MIME 等主要用途。这不是“所有非浏览器都排除”的句子，却说明章程有能力明确列出边界。

证据允许的结论是存在解释张力，而不是已经违章。若工作组认为其互联网服务器授权足以包含这些需求，应公开指出是哪一条、由谁解释，以及未获投票资格的软件群体如何参与。若“附属活动”被使用，也应说明它为何是附属而非无限扩张的容器。

东京会议已把这道裂缝写入记录

2025 年 3 月的 SCWG 第 64 次面对面会议，专门讨论了 TLS BR 的范围。会议纪要逐项记录浏览器与非浏览器用例、操作系统信任库、服务器到服务器连接、私有 PKI、敏捷性与新建工作组的可能性。

一种看法认为，浏览器根计划构成 BR 的运行现实，非浏览器系统不应拖慢 Web 安全演进。另一种看法指出，操作系统和应用共用这些根，非浏览器用户缺少替代标准，过度浏览器化可能造成证书与根库碎片化。

纪要最后保留两种视角，没有选择胜方，也没有修订章程。其作用不是赋权，而是证明 SC-106 遇到的并非突然出现的新异议：机构早已知道运行使用面与投票定义不完全重合。

2026 年 PR 评论把同一问题带回公开记录。一位参与者直接称重点用例为 non WebPKI。Ben Wilson 认为保证强度取决于依赖方实际构建和接受的路径，一条独立的全后量子路径不会因另有经典路径而改变。后续 Chrome 参与者把两种混合链方向分开，质疑非浏览器需求与章程是否匹配，并建议考虑新的 CA/B Forum 工作组。

这些都是有署名的立场。GitHub 点赞数不是票数，厂商意见也不是工作组决议。

“纯链”争论实际上画出了权限地图

草案的论证是：呈现路径中只要有一个经典签名，该路径就只能提供经典保证。反对意见并不必然否定这点，而是问配置规范是否需要禁止所有混合结构。依赖方可以只接受全后量子路径并忽略经典替代；另一条路径存在，并不会改写已接受路径中的签名。

RFC 5280 将 prospective certification path 与 trust-anchor information 列为路径验证输入，并明确根锚选择属于策略。不同路径无需从同一根锚开始。BR 能限制 CA 发行什么，却不会自动选择客户端使用哪条路径。

这也不证明草案限制错误。经典 CA 为后量子订户密钥签名，与后量子 CA 为过渡期经典密钥签名，可能带来不同的 CT 负载、降级和兼容影响。共同规则可以保护共同不变量，但必须把不变量写清：是 Web CT 容量，是“后量子路径”标签的完整性，是根信号，还是某一阶段的降级保护？

若同一限制同时声称解决路径强度、日志容量、遗留兼容和非 Web 迁移，它就会把多个控制者的决定提前塞进共同层。

运行实现展示的是多条路线

Chromium 的公开路线图是一条面向 Web 的分阶段方案：证书协商、经典与后量子凭据并行、降级保护，以及在很远未来移除经典选项。Chrome 对公共 Web 更偏向 Merkle Tree Certificates，而不是把传统 ML-DSA X.509 直接放入其生产根计划。

Chrome Quantum-resistant Root Program 的测试说明把边界变成可观察状态。从 Chrome 150 起，传统 ML-DSA 证书可用于私有 PKI。另一个 MTC 测试根库则需单独启用，cosigner 被标记为仅供非生产验证，并有自己的日志、镜像与算法要求。

这不是 Chrome 替所有设备作出的答案。它证明不同兼容集能够并存：私有层级、实验根库与未来生产政策无需被一份文档提前合并。

FIPS 204 规定算法；证书配置规范规定编码与发行；根政策决定信任；CT 决定透明度与承载；客户端决定路径；部署记录证明运行结果。Lu Heng 的“最小初始规范—本地未来决定—自愿采用”纪律在此不是反标准化口号，而是要求每一层只声称自己真正拥有的决定。

一份足够短、也足够严格的授权回执

回执首先应记录提案身份：base、commit、状态、正式 proposer 与 endorser、讨论和投票区间、票数、IPR、最终版本与生效日。其次逐类列出浏览器、操作系统验证器、SDK、嵌入式客户端、IoT、中间件、私有 PKI 和公共服务，不用一个宽泛标签遮蔽差异。

第三部分把每类需求连到具体章程条款，指出解释主体、投票路径、咨询路径以及没有正式路径的群体。无投票权不等于否决权；它只禁止声称这些群体已经被代表。

第四部分逐项拆开密钥编码、证书路径、降级、CT 容量和根准入，注明共同不变量、决策所有者、可用证据与可否保留为本地选择。第五部分列出实现版本、测试向量、证书大小、路径结果、根试验与失败。

最后比较制度场所：在 SCWG 内以公开解释推进、澄清或修改章程、建立非浏览器消费者工作组，或暂由根计划进行有限试验。每项过渡限制还需要复审日、触发阈值和退出方法。

9 月 2 日不能得出的结论

现有资料不能证明 SC-106 已采用、无效、没有必要或技术上已完成。没有工作组对章程作出集体解释，没有被点名客户端的需求普查，也没有生产根库与 CT 容量结论。

Chrome 路线图不是 Forum 决议，Mozilla 参与者评论不是密码学裁判，PR 前言不能代表操作系统厂商。官方状态页缺席只能证明观察时的公开状态，不能推断隐藏意图。

这正是现在修复记录成本最低的原因。若等到审计、采购和发行工具把 SC-106 称为“行业标准”，制度出处会被运行依赖反向固化。

明确授权不会削弱配置规范

若 SCWG 认定互联网服务器条款足以承载这一配置，它可以公开解释，并把对非 Web 群体的代表性主张限制在证据范围内。若设备、SDK 和系统客户端的约束与 Web CT 不同，新工作组可能更合适。若各根计划已经能够试验，共同文本也可以等待运行数据。

这些选择都不反对 ML-DSA。真正的问题是，不能让文件存放的位置代替授权论证。

SC-106 已经承认配置许可不等于根信任，证书签名不等于 SCT 签名。下一步也应承认：受益者不等于表决者。把两者写入同一张回执，技术文本才能保持它应有的窄而强。

来源

  1. Lu Heng，《The Multi-Stakeholder Mirage》
  2. Lu Heng，《Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption》
  3. CA/Browser Forum，servercert pull request 679 — SC-106
  4. SC-106 不可变对比
  5. 冻结 head 上的拟议 TLS Baseline Requirements
  6. Server Certificate Working Group 章程
  7. SCWG 第 64 次面对面会议纪要
  8. CA/Browser Forum Bylaws
  9. SCWG ballot 状态页
  10. NIST FIPS 204
  11. RFC 5280 第 6 节
  12. Chromium，后量子 HTTPS 认证路线图
  13. Chrome Quantum-resistant Root Program 测试说明