摘要

  • IANA 把算法编号 18 分配给 ML-DSA-44，并将签名、验证的使用状态标为 MAY。提交 DS 数据还要经过注册局的 EPP 规则。
  • Joe Abley 在 RIPE 93 指出这道上游门槛。他的 10 月个人草案建议，注册局和注册商按 IANA 的 DNSSEC 算法与摘要注册表制定接收规则。

编号已经有了，交易却可能在下一个窗口被挡住。

10 月 29 日的 RIPE 93 DNS 会议上，Joe Abley 讲述了他通过 EPP 提交算法 18 的尝试。他说，在自己检查过的系统中，没有注册局接收这一数值；随后他提到一个例外：与 Garth Miller 交流后，有维护者合并了一项代码修改。一次讨论加一次合并，打通了一条路径，却没有给其他注册局留下可预测的规则。

IANA 的 DNSSEC 算法表目前把编号 18 列作 ML-DSA-44。该算法可用于区域签名；其签名和验证使用及实现要求标为 MAY。这些字段记录了允许的要求级别；注册局、签名器和验证解析器的部署情况属于另一个运行状态。

EPP 里的细节很小，却决定数据能不能走到父区。RFC 5910 规定如何通过 EPP 携带 DS 数据。alg 字段指出 DS 所引用 DNSKEY 的算法，digestType 指明生成 DS 摘要所用的算法。Joe Abley 在 10 月 14 日提交的个人草案只处理这两个字段，建议把 IANA 的 DNSSEC 算法和摘要注册表作为共同规则，同时排除无法提供 DNSSEC 安全性的取值。Datatracker 目前只列出个人草案第 00 版，状态为 I-D Exists；它没有 IETF 标准地位。

控制点因此清楚了：签名方可以准备新算法，IANA 可以分配编号；父区注册局仍决定注册商能不能提交这条 DS。请求被拒后，子区就无法完成算法更换所需的父区步骤。没人公布的本地白名单，会把标准演进变成猜谜。

接收与验证是两项决定。解析器若不支持某算法，就会忽略对应 DS；没有剩下可支持的 DS 时，该解析器会把子区视为未签名。EPP 负责开放提交路径；解析器支持情况是另一项部署工作。

草案关于政策差异的主张缺少列出注册局名称、测试日期和 EPP 接收值的矩阵；公开这份矩阵才能说明差异范围。

一手来源：RIPE 93 演讲 · RIPE 93 会议文字稿 · IANA DNSSEC 算法注册表 · RFC 5910 · RFC 4035 · Joe Abley 的个人草案，第 00 版。