摘要

  • RFC 9935 为 ML-KEM 私钥规定种子、展开密钥和二者并存三种形态，接收方应依 ASN.1 标签识别，不能靠长度猜测。
  • 收到并存形态时，应从种子重新生成展开密钥并比对；若执行校验后发现不一致，必须拒绝该私钥包。

密码迁移最危险的“成功”，往往是导入界面显示绿色，但系统没有记录自己究竟验证了什么。RFC 9935 把这个问题落在一个非常具体的控制点上：ML-KEM 私钥进入 X.509 基础设施时，表示形式与密钥一致性不是同一件事。

公开部分的规则很严格。ML-KEM-512、768、1024 分别使用 NIST 分配的 OID，算法参数必须缺省，公开密钥长度也固定。证书若带 keyUsage，只能标记 keyEncipherment。这些字段能够说明“它自称是什么、字节应怎样读”，却不能说明证书链已经通过、用途已经批准，或某个主体确实控制相应私钥。

私钥有三种选择。seed 保存 64 字节，其中前后各 32 字节作为 d 与 z，可确定性生成展开解封装密钥和公开密钥。expandedKey 直接保存更大的解封装密钥。both 同时保存两者，让保留种子的系统与只支持展开密钥的系统交换材料。

解析器必须看标签：上下文标签 [0] 是种子，OCTET STRING 是展开密钥，SEQUENCE 才是并存形态。识别 SEQUENCE 只证明两个字段存在。它没有证明二者之间存在正确的派生关系。

这项关系需要接收方实际计算。RFC 9935 要求接收方对并存形态应当从种子重新执行规定的生成过程，再与附带的展开密钥逐字节比较。接收方可以为了省去计算而不做，但后果不是“低保证通过”，而是根本无法确认两者匹配。一旦做了检查并发现差异，标准要求把该包判为格式错误并拒绝。

因此，审计记录应分层：结构已解析、形态已识别、比对已执行、比对通过、导入已接受、密钥已使用。前一层不能代替后一层。尤其不能把“私钥文件可读”写成“密钥有效”。

展开密钥还有独立检查。FIPS 203 要求在解封装前检查候选密钥的类型、长度和内部哈希。它还给出更广的密钥对检查，包括存在种子时的一致性验证，以及一次成对封装/解封装测试。即使这些步骤全部通过，也不保证该密钥对确由标准生成算法正确产生。

种子保留策略则带来不可逆选择。从种子生成展开密钥是确定性的；种子一旦丢弃，无法由展开密钥反推回来。保留种子有利于紧凑备份、迁移和恢复，但它本身是可重建整套密钥的高价值秘密。只保存展开形态减少一种留存，却封死未来需要导出种子的路径。

RFC 5958 提供 OneAsymmetricKey 容器，RFC 9936 说明 CMS 如何指向收件人证书与密文。它们都不能替代本地导入证据：谁执行了比较、用哪个实现、得到什么结果、为何接受或拒绝，以及后续是否发生转换。

日志不应复制私钥字节。合格回执可保存输入包指纹、声明形态、算法标识、解析器版本、检查项目、结果、决策和转换去向。这样既能证明控制动作，又不会制造新的秘密副本。

来源