摘要

  • RFC 9882 为 CMS SignedData 规定纯 ML-DSA-44、ML-DSA-65 和 ML-DSA-87，不规定 HashML-DSA。
  • signedAttrs 的有无分开了两条路径：eContent 值八位组，或完整 DER SignedAttrs。

完整 OID 为 2.16.840.1.101.3.4.3.17、2.16.840.1.101.3.4.3.18 和 2.16.840.1.101.3.4.3.19。ML-DSA AlgorithmIdentifier 参数必须省略，ML-DSA 上下文字符串为空。

有签名属性时，摘要必须同时针对第二原像攻击和碰撞攻击提供该 ML-DSA 参数集的 lambda 位安全性，输出至少为 2*lambda 位。总体强度取摘要和 ML-DSA 中较低者。表 1 的完整集合是：ML-DSA-44—SHA-256、SHA-384、SHA-512、SHA3-256、SHA3-384、SHA3-512、SHAKE128、SHAKE256；ML-DSA-65—SHA-384、SHA-512、SHA3-384、SHA3-512、SHAKE256；ML-DSA-87—SHA-512、SHA3-512、SHAKE256。必须支持 SHA-512，建议支持 SHAKE256；两个标识符都省略参数。

双路径字节夹具。 路径 A 仅在没有 signedAttrs 时使用。它只签署 eContent OCTET STRING 的值八位组，不包括标签和长度八位组。为保证互操作性，签名方在 digestAlgorithm 中编码 SHA-512；但该字段在路径 A 没有密码学含义，验证方忽略其内容。路径 A 不包含 content-type 或 message-digest，也没有签名属性消息摘要或内容哈希重算要求。路径 B 在存在 signedAttrs 时使用。它签署完整的 SignedAttrs DER 编码，包括标签和长度，并使用显式 SET OF 标签，绝不使用最终消息的隐式 [0]。路径 B 至少包含 content-type 和 message-digest；只有路径 B 要求接收方重新计算内容哈希并与 message-digest 比较。

签名属性中应包含 CMSAlgorithmProtection，以抵抗算法替换。这是规范性建议，不是部署现状的推断。大内容可以留在 HSM 签名边界之外。纯模式消息代表 mu 的外部计算得到 RFC 9881 附录 D 和 FIPS 204 第 6.2 节的说明。HSM 接口控制和发布顺序属于 Theo March 分析。hedged 签名与确定性签名使用相同验证器；担心侧信道或故障攻击时，不应使用确定性签名。

运维解读

规范性边界来自 RFC 9882、RFC 5652、RFC 6211、RFC 9881 和 FIPS 204。Theo March 分析建议记录路径、字节长度和指纹、OID、参数省略、标签、属性、摘要标识、路径 B 的内容哈希比较、HSM 边界和验证结果。分阶段启用、影子验证和回滚测试是建议，不是 RFC 强制要求，也不是采用率声明。RFC 9881 讨论 PKIX 编码，RFC 9879 不属于本简报范围。

来源