摘要

  • 没有签名属性时，RFC 9882 为降低互操作失败而强制在 digestAlgorithm 写入 SHA-512；但纯 ML-DSA 直接签内容，验证者必须忽略这个字段。
  • 存在签名属性时，内容摘要才成为实质校验环节：接收者要重新计算摘要，再验证 SignedAttrs 的完整 DER 编码。
  • 合格证据链必须先确定实际分支、签名字节、参数集 OID、算法绑定和计算边界，最后另行判断签名者是否有权触发业务动作。

RFC 9882 中最值得管理者注意的字段，并不是一个能决定计算的字段，而是一个必须填写、又必须被忽略的字段。CMS 的 SignerInfo 如果没有 signedAttrs，签名者必须把 SHA-512 写进 digestAlgorithm。接收者验证这种 ML-DSA 签名时，则必须忽略该字段内容。

这不是标准自相矛盾。纯 ML-DSA 面向整段消息签名，不消费外部先算好的内容摘要。SHA-512 在这里承担的是兼容作用：CMS 软件习惯看到摘要算法标识，填入通行值可以减少互操作故障。它证明发送者遵循了一项格式约定，却不证明 SHA-512 曾经处理内容。

真正的签名输入有严格边界。没有签名属性时，输入是 encapContentInfo eContent 中 OCTET STRING 的值字节，不包括标签和长度字节。因此审计记录至少要保留收到的 CMS 对象、解析出的分支和重建后的输入指纹。只导出 digestAlgorithm=SHA-512，会得到形式整齐却事实错误的执行说明。

一旦出现 signedAttrs，路径随之改变。ML-DSA 签的是 SignedAttrs 值的完整 DER 编码。验证时要使用 EXPLICIT SET OF 标签，而不是最终 CMS 结构里的 IMPLICIT [0] 标签。属性中至少包括 content-type 和 message-digest；接收者必须重新计算内容摘要，并与受签名保护的 message-digest 比对。

在这个分支里，摘要算法确实产生安全含义。RFC 9882 分别讨论 ML-DSA-44、ML-DSA-65 和 ML-DSA-87 所需的摘要强度，要求实现支持 SHA-512，并建议支持 SHAKE256。由此可见，同名字段的证据价值取决于相邻结构。日志若只有字段、没有分支，就无法回答计算究竟如何发生。

“ML-DSA”这一总称同样不够。三个参数集各有 OID，签名 AlgorithmIdentifier 的参数必须缺省。RFC 9882 为 CMS 规定的是纯 ML-DSA，并未规定 HashML-DSA。产品界面显示一个家族名称，不能证明参数集、编码规则和输入模式。

算法替换还要单独防范。RFC 6211 定义 CMSAlgorithmProtection，把相关算法标识复制到受签名保护的属性里。RFC 9882 建议在签名属性中包含它。核对这个属性，可以保护一个具体连接点；它不能替代内容摘要比对、DER 重建、ML-DSA 验证或证书路径判断。

密码学有效也不等于机构授权。某把私钥可以对正确字节生成有效签名，持有者却未必有权批准付款、发布版本或修改网络配置。反过来，有权的人也可能通过错误管线签了错误表示。身份、角色、授权范围、时间和应用决策都要保留各自记录。

硬件边界也可能比“由 HSM 签名”这句话更窄。使用签名属性时，送入设备的可以只是较小的 DER 属性集。纯 ML-DSA 还允许在另一个密码模块中预先计算消息表示 μ，再交给硬件签名。HSM 成功收据本身不能证明设备看过原文，也不能证明是谁编排属性、谁计算 μ。

验证结果同样看不出随机性策略。ML-DSA 默认的 hedged 方式结合新鲜随机数与私钥中的预计算随机材料；FIPS 204 也容许确定性签名。RFC 9882 提醒，在担心侧信道或故障攻击的平台上不应使用确定性变体。两者使用同一种验证算法，必须从签名端的运行证据区分。

所以，一条可辩护的链条应依次回答：收到了什么对象；是否存在 signedAttrs；重建了哪些签名字节；使用哪个参数集 OID；参数是否违规出现；内容摘要是否需要且完成比对；算法保护是否一致；签名是否有效；μ 在哪里计算；私钥在哪里使用；签名者是否有业务权限；应用最终做了什么。RFC 9882 规定其中若干连接，却没有把整条链压缩成一个绿色状态。

来源