摘要

  • KEMRecipientInfo 中的 rid 标识收件人证书或公钥，kem 标识 ML-KEM 算法，kemct 是为该收件人生成的密文。
  • 这些字段可证明 CMS 对象采用了某一密钥路径，却不能证明谁在何时控制私钥、解封是否成功、应用是否接受内容或组织是否授权后续行动。

审计记录里出现了收件人标识、算法和密文，往往会被写成“收件人已经处理”。这一步跳得太远。

RFC 9936 规定 ML-KEM-512、-768 和 -1024 如何通过 KEMRecipientInfo 用于 CMS。发送方用收件人的公有封装密钥生成密文和共享秘密；收件方用私有解封密钥及该密文生成相应的共享秘密。规范的用途是传递内容加密密钥。

这使 CMS 对象成为很好的格式证据：可以检查它为哪一公钥路径准备、使用哪一算法和密文。它不是私钥仍受谁保管的证明，也不是一个已读、已批准或已执行的回执。

证书放入的是公钥，不是行动

RFC 9936 要求 ML-KEM 收件人使用 OtherRecipientInfo 中的 KEMRecipientInfo。rid 对应证书或公钥；kem 是算法；kemct 是相应密文；KDF 与密钥封装字段服务于内容密钥的传递。发送方从收件人证书取得静态公钥，具体承载约定见 RFC 9935。

证书因此是密钥分发上下文，而不是实时的私钥保管证明。它不能单独说明私钥是否仍在受控模块内、谁拥有使用权限、撤销状态如何处理，或哪个本地进程实际使用了它。SMIMECapabilities 也只可以声明实现支持的部分算法；“可以支持”不等于“此消息已被处理”。

真正决定性的步骤仍在本地

封装使用公钥，解封使用私钥和密文。这两项操作的输入、责任和审计位置不同。RFC 9936 要求保护 ML-KEM 私钥及相关密钥、使用后清除临时密钥并防范薄弱随机性；一个格式正确的 CMS 对象却不能证明某个部署满足了这些要求。

认证或加密的 CMS 容器也不能替代业务事实。它可在规定条件下保护内容，却不规定收件箱、应用验收、证据保留或组织授权。亨路笔记的有用提醒在于：公共、可验证的事实应保持在其可验证的范围内；标注一条路径，不会让路径之外的行动自动发生。

应分层保存 CMS 对象和字段、证书验证结果、私钥保管和访问记录、解封及本地认证结果、应用接收记录，以及最终决策的授权材料。每项记录只回答自己的问题。

来源