摘要

  • 2026年9月10日，IESG 驳回一项申诉，解除发布搁置，并发出对 draft-ietf-tls-mldsa-05 的批准公告。该草案规定怎样在 TLS 1.3 认证中使用 FIPS 204 的 ML-DSA 签名；预定状态为信息类 RFC。查证时它仍是没有 RFC 编号的 Internet-Draft。
  • IANA 的 TLS SignatureScheme 登记表已收录 mldsa44、mldsa65 和 mldsa87，数值分别是 0x0904、0x0905 和 0x0906，三项均标为 N。RFC 9847 所定义的 N 是 IETF 未作适用性声明或没有共识，不是表示不建议使用的 D。
  • 批准发布、分配互操作标识和建议部署是三种不同的行为。申诉决定终结的是提交给 IESG 的程序争议，不是替所有运营者选择纯 ML-DSA 或复合签名。
  • 采用者应另建一份部署凭据，写明 TLS 使用面、参数和签名方案、证书与对端范围、带日期的证据、失败阈值、回退责任人和复核时间。代码点是共同索引，不是开机命令。

已经完成的是发布决定

Datatracker 的时间线给出了两个不同阶段。IESG 曾在7月8日批准文件，随后因收到申诉而把发布置于搁置状态。9月10日，IESG 驳回申诉、解除搁置并重新进入已发批准公告的状态。正式公告将其列为 TLS 工作组成果，预定作为信息类 RFC 发布。

公开记录没有把分歧抹平。文件负责人概述称，围绕是否继续推进约有275封邮件，支持与反对大致为四比一。争论包含数种主张：不应发布纯 ML-DSA；应推荐复合签名；或者让纯方案和复合方案同时推进。IESG 的申诉答复说，它检查了工作组最终征求意见阶段的反馈，认定支持面广，反对意见也得到考虑和讨论，因此维持粗略共识判断并驳回申诉。安全领域主任 Deb Cooley 没有参加该项决定。

这份答复证明的是发布决定在程序上成立。它没有证明每项技术顾虑都已消失，也没有把大约四比一变成一项部署表决。粗略共识允许群体在仍有异议时继续形成规范；某一服务是否接受算法、实现和证书链的风险，仍由该服务的责任主体回答。

“批准”也不等于“已经拿到 RFC 编号”。当前文件页面显示 Approved-announcement sent，同时仍把第05版列为有效 Internet-Draft。IANA 审查状态是 Version Changed - Review Needed，处理状态是 In Progress。这条生产链尚有可观察的最后步骤，报道不应抢先替它完成。

三个登记值消除一种歧义

FIPS 204规定了 ML-DSA 数字签名算法。获批草案所做的事情更窄：让 TLS 1.3 的签名算法扩展能够协商三个参数集。ML-DSA-44 对应 mldsa44 和 0x0904，ML-DSA-65 对应 mldsa65 和 0x0905，ML-DSA-87 对应 mldsa87 和 0x0906。

RFC 9881已经给出三种算法在 X.509 中的 AlgorithmIdentifier。新草案把这些标识与 TLS SignatureScheme 接通。使用某一数值执行 CertificateVerify 时，签名和验证按 FIPS 204 进行，ctx 参数为空字符串；终端实体证书必须使用相应 AlgorithmIdentifier。这里不采用 HashML-DSA 的预哈希变体。

这些约束能让互不隶属的实现产生并识别同一种线上表达。它们没有证明某家证书颁发机构会提供相应证书、浏览器会接受整条链、密钥能在既有硬件边界中安全处理，或混合版本的机群能够无损回滚。语法互通是一项必要证据，却不是完整的运营结论。

IANA 实时登记表已经显示三项数值和 N。表中引用的仍是较早草案版本，而 Datatracker 又显示 IANA 工作正在进行。因此最准确的状态是：数值已经分配且公开可见，文件引用和最终发布环节仍未全部收束。

N 不是否决票

在普通表格里，字母 N 很容易被理解成“No”。RFC 9847采用的却是三态治理语义。Y 表示 IETF 形成共识，认为该项目适合其所定义的用途，仍须阅读适用范围；D 表示不建议使用，并且必须给出理由；N 表示 IETF 未评价适用性、未作适用性声明或没有共识，也可能反映适用面有限或存在使用约束。

RFC 9847 特别说明，N 不一定意味着机制有缺陷。因此，获分配的登记值不是绿灯，N 也不是红灯。登记表可以先让试验和实现使用同一名称，同时诚实保留尚不存在普遍推荐这一事实。

把代码点当成认可，会让名录维护意外变成安全审批。把 N 当成拒绝，则会把“尚未形成适用性结论”改写成“已判定不可用”。这两种读法都给共享层增加了它没有声称拥有的权限。

纯方案与复合方案仍是两个不同对象

本次获批文件描述纯 ML-DSA。另有一份有效的个人 Internet-Draft描述 TLS 1.3 中的复合 ML-DSA，把后量子签名与传统签名组合。Datatracker 明确说明，该个人草案没有 IETF 文档流的认可。它证明有另一项设计正在被具体化，不证明 IETF 已把两条路线置于同等制度地位。

具体选择依赖威胁模型。纯方案不需要对第二个签名也作成功验证，却把保障集中在 ML-DSA 及其实现。复合方案可以在新算法或代码出现问题时保留传统组件，但会增加证书和消息体积、计算量、配置复杂度与互通失败点。信息类文件获批不能替每个网络算完这笔账。

公告列出的实现名称也只能证明代码路径存在。OpenSSL、BoringSSL、rustls-post-quantum、s2n-tls、wolfSSL、Bouncy Castle 或 GnuTLS 出现在清单中，并不等于默认启用、承载生产流量、证书链已经普遍可用、性能达标，或跨机群撤回经过验证。

部署凭据应由承担风险的人签发

第一项记录应是准确的 TLS 使用面，而不是“后量子就绪”口号。它需要区分服务器认证、客户端认证、受限私有服务与公开试验，写明 ML-DSA 参数，并明确是纯方案还是复合方案。

第二项是人口边界：哪些颁发方、证书配置、端点、客户端、库版本和硬件密钥边界在范围内。协商失败必须有预先规则。对端未声明新值时，是拒绝连接、切换证书、转移流量，还是回退到允许的算法？如果回退不可见，连接可能继续正常，而预期获得的保障已经不存在。

第三项是带日期的证据。互操作测试应跨越不同实现家族，不应只让同一库的两个版本互连。性能测试要覆盖现实并发下的握手大小、处理器占用和延迟。安全审查要落到真实运行边界中的密钥生成、签名、验证、随机或确定性模式以及侧信道。证书颁发与完整验证链也须连起来测试。

最后要写清谁能扩大范围、谁能关闭功能、哪些遥测触发回滚、已经分发的密钥与证书如何退出、证据何时过期，以及何时重新审议。这份凭据不改变 IETF 的结论；它完成 IETF 无法替某个运营者完成的决定。

证据边界

现有来源不证明三种方案已默认启用或广泛进入生产；不证明纯方案或复合方案普遍更优。驳回申诉是程序判断，不是密码学证明。NIST 制定 ML-DSA 标准，不等于评估某个 TLS 部署。登记表已有数值，也不等于 IANA 和 RFC Editor 的全部处理已经结束。

可以确认的结论更小：IETF 已批准发布一套让三个 ML-DSA 参数在 TLS 1.3 中获得互操作含义的规范，同时登记表继续明确标注 N。下一项可问责决定属于采用者，也应拥有独立的证据记录。

来源

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Use of ML-DSA in TLS 1.3 批准公告
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — 文件历史
  7. IESG — 对申诉的答复，资料320
  8. IANA — TLS 参数登记表
  9. RFC 9847 — TLS 与 DTLS 的 IANA 登记表更新
  10. NIST — FIPS 204，ML-DSA 标准
  11. RFC 9881 — ML-DSA 算法标识
  12. RFC 9846 — TLS 1.3 协议
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3