摘要

  • RFC 9964 的 AKP 要求 alg 和 pub，并明确分开公开与私有材料，使 ML-DSA 能在 JOSE 与 COSE 中被一致表示。
  • priv 只容纳 32 字节种子。种子与展开私钥一旦泄露都能导致伪造签名；紧凑编码并未减轻保管义务。
  • 指纹可比较公开密钥和算法；签名是否被允许、何时轮换、服务接受什么后果，仍在指纹之外。

同一把密钥，未必同一项权力

JOSE 和 COSE 需要能够携带 ML-DSA 的共同密钥形式。RFC 9964 为此定义 AKP，并登记 ML-DSA-44、ML-DSA-65 和 ML-DSA-87。算法与公开材料不可缺少，私有字段不能出现在公钥中；指纹又只由 kty、alg 和 pub 等公开输入构成。于是不同系统可以问一个有限而重要的问题：它们是否正在谈论同一公开密钥和同一算法。

这是互操作判断，不是权力归属。指纹没有种子，也不写入某个人、机构或审批流程。目录里公开一条指纹可以帮助核对材料，却不能由此决定谁可以使用种子、谁可以发起轮换、或哪一个服务必须服从一次签名。把能比较的对象误当成能治理的对象，是加密项目最容易发生的语义跳跃之一。

FIPS 204 允许私有材料以种子或展开形式存在。RFC 9964 选择前者，是为了让两个生态系统获得一份紧凑、单一的表示，而不是让每个实现都携带多种等价私钥。标准同时说得很清楚：两种形式都需要同等保护。获得其中任何一种，攻击者都可能生成签名。序列化歧义被消除了，备份副本、恢复通道、硬件边界、委托和人员离职带来的保管问题并没有随之消失。

因此应把几类记录分开。公开 AKP 和指纹是一条密钥证据；种子或展开材料在何处、由谁保护，是保管记录；一次签名请求的目的与范围是操作记录；批准该请求的是授权记录；接收方究竟接受还是拒绝其效果，是服务记录。它们会相互关联，但不能相互替代。一把正确的密钥可以被拒绝使用；一个通过验证的签名也可以被服务拒绝。

较大的算法不会自动带来较大的中央权威

ML-DSA 的尺寸使这个边界更显眼。公钥和签名较传统选择大得多，JSON 编码又会增加体积。RFC 9964 特别提示，受网络、内存或处理能力限制的环境未必合适。这是一项部署约束，不是一张让中心节点替所有人下令的许可证。各参与方可以测量自己的路径，选择适配的参数集，拒绝不适配的配置，并在验证期间保留替代路径。

同样，标准存在不表示某一系统已经采用。一个组件能验证 ML-DSA 签名，不能证明每个依赖组件都接受该算法、尺寸和用途。卢恒所强调的“最小初始规范、局部未来决定、自愿采用”在这里不是口号：共同层严格约束表示、比较和验证；承担运营后果的节点则自行决定保管、授权、接受和退出的条件。

良好的审计链不应只留下“签名有效”。它应能回答：这枚公开键是如何识别的；私有材料由什么机制保护；此请求代表何种行动；谁在何种时限内批准；接收端检查了哪些额外条件；若事后发现授权错误，怎样停止未来使用并恢复相关服务。标准的边界越清楚，本地责任越不应被一块“加密成功”的绿灯吞没。