摘要

  • RFC 9964 引入通用的 Algorithm Key Pair（AKP）类型，并为 JOSE 与 COSE 注册 ML-DSA-44、ML-DSA-65 和 ML-DSA-87，使密钥材料与算法参数有一致的表达方式。
  • alg、pub 和有效的签名验证解决的是密码学表示与计算问题；它们并不自行确定密钥来源、发行者信任、主张核验或授权决定。

密码系统很容易把“可解析”误认为“可接受”。一个对象带着已知的 alg，软件就能选择算法、检查参数，并决定怎样处理 pub。这是一种重要的确定性。可是，确定对象是什么，不等于确定对象应当产生什么后果。信任是把经过验证的密码学事实连接到机构责任、业务语境和行动权限的另一层判断。

RFC 9964 为第一层建立了清晰的边界。Michael Prorock 与 Orie Steele 在这份 IETF Standards Track 文档中规定了 ML-DSA 密钥与签名如何用于 JOSE 和 COSE，并引入 Algorithm Key Pair，简称 AKP。AKP 是一个通用结构，并不局限于本文档所登记的算法。所有 AKP 密钥都必须有 alg 和 pub；priv 保存私有信息，不能出现在公开密钥中。对实现者而言，这些规则把本来可能含混的密钥形状变成可互操作、可检查的约束。

对私钥的选择尤其能说明其范围。FIPS 204 对 ML-DSA 给出种子和由种子展开的私钥两种表达。RFC 9964 只选择种子表示：priv 必须是长度为 32 字节的种子。这样做让 JOSE 和 COSE 使用同一种紧凑形式，减少密钥管理中的歧义。它没有说明是谁生成了种子、种子是否妥善保管、相关公钥通过何种渠道送达，或任何依赖方是否应据此接受一项声明。

ML-DSA-44、ML-DSA-65 与 ML-DSA-87 的注册也是同样的事情。它让参与者能够在 JOSE 与 COSE 注册表中指向共同的参数选择。注册表不因此成为信任名册：它不选择信任锚，不证明公钥归属于某一主体，不验证签名载荷中的身份和条件，也不决定一个通过验证的对象可以开启访问、交换数据或承担何种义务。每一项都需要独立的证据与可追责的政策所有者。

该文档还提醒，ML-DSA 的公钥和签名较大；在带宽、内存或处理能力受限的场景中，它们可能并不合适。这不是对某个实际部署的判断，而是把“格式正确”与“运行适配”分开。RFC 9964 把详细的安全分析留给 FIPS 204 和 RFC 9881。标准没有假装能够替应用环境作完全部决定。

因此，Prorock 的共同贡献不在于把一个算法名称升格为信任结论，而在于为跨系统携带的密钥材料给出严格的语言。表示层可以因标准而稳定；密钥分发、信任锚、主张语义和最终行动仍须由承担责任的依赖方明确决定。

Sources