摘要

  • RFC 9980 允许迁移期同时向 PQ/T 和传统密钥发送，以维持兼容；这并不会让含有传统解密路径的同一封邮件自动获得后量子保密性。
  • 需要验证的是实际选中的收件人密钥、生成的 PKESK 包和相应例外决定，而不是密钥目录里是否出现一个新算法名称。

新密钥不是整封邮件的安全标签

看到目录中出现 ML-KEM-768+X25519，很容易把它写成“这个收件人已经抗量子”。这句话跳过了太多步骤。标准可以规定算法编号、包格式和必要的密码操作，却不能证明某个客户端已经实现该算法，不能证明密钥的身份绑定，也不能证明它在某次发送中真的被选中。

OpenPGP 的收件人设计正好说明了这种差别。一封邮件可以含有多个公钥加密会话密钥包（PKESK）：每个包让相应收件人以自己的密钥取回同一把内容会话密钥。RFC 9980 第 8.1 节允许在迁移中同时放入 PQ/T 与传统 PKESK，以避免旧端无法收信。这一做法服务于连续性；它没有消除传统路径。第 3.1 节因此限定，只要其中任何一把用于收件人包的密钥不是 PQ(/T)，该邮件的保密性就不能称为后量子保密。

这不是要求一律拒绝旧收件人。某个合作方可能尚未升级，某类业务消息可能有经批准的恢复安排。关键在于，保留传统路径改变的是该邮件的密码学属性，不能被“我们也加入了新密钥”掩盖。例外应对应明确的消息类别、负责人、终止日期和替代计划。

复合密钥和并列收件人包不是同一件事

RFC 9980 的复合 KEM 不只是把两个算法名称放在一起。它把 ML-KEM 与 ECDH KEM 作为一把 PQ/T 收件人密钥的两个组成部分；发送时各自封装，再把两个密钥份额、ECDH 密文、收件人公钥和协议上下文一起输入组合器，得出用于包裹会话密钥的密钥。该收件人路径的解密依赖这一特定构造。

在同一封邮件里另加一个传统 PKESK 的含义完全不同。它是通向同一会话密钥的另一条独立路线，不是复合构造中的第二个部件。若仪表盘只显示“混合算法存在”，就可能错过真正应问的问题：这封内容实际可以被哪些密钥路径解开？审计应检查出站包的形状，而非仅检查组织已采购或登记了哪些能力。

签名迁移不能替代收件人治理

签名采用的是另一种兼容逻辑。发送方可以同时使用传统密钥和 PQ/T 密钥签名，让旧实现仍可依赖传统签名；只使用 PQ/T 签名则不向后兼容。较新的验证方可以接受两者，也可以在知道对端已有 PQ/T 签名密钥且量子风险相关时选择忽略传统签名。

这不代表签名验证了身份、职权、内容真实性或收件人同意。它只说明，加密的收件人策略与签名的验证策略是两套不同的本地决定。把它们都压缩为一个“已启用 PQC”的状态，会让依赖方看不见自己的真实选择。

应保存可复核的最小证据

绝大多数 PQ(/T) 非对称算法需要 v6 或更新的密钥和证书；ML-KEM-768+X25519 可用于特定的 v4 加密子密钥。RFC 9980 规定了必要实现项，IANA 登记了 30 至 36 号算法标识。这些都是解释包的共同词汇，不是部署证明。

合理的记录不需要复制邮件正文。它可以保存消息类别、所选密钥及版本、算法、实际生成的 PKESK、已知的能力验证结果，以及批准传统路径的决定。这样既能重放“为何这封邮件不能或可以使用某种表述”的判断，又不会把迁移项目变成新的通信内容库。

来源