摘要

  • 7 月的 AuthKEM 00 版在第 6.3 节提出四消息变体：发起方在第一条消息中明文发送 ID_CRED_I，草案明确承认这会牺牲发起方的身份保护。9 月 28 日的 01 版已无这一节。
  • 01 版明确列出五条必需消息。响应方须核验第五条消息，才能完成对发起方的认证并导出应用密钥；发起方的完成节点在处理第四条消息并构造第五条消息之后。
  • 草案建议的方法编号“5”还不是 IANA 已分配的值。KEM 认证方法本身不保证抗量子，只有选用合适的后量子 KEM 才能支持该主张。

一份标准草案的删除项，往往比新增术语更能说明设计边界。AuthKEM 00 版允许把发起方的凭据标识放进第一条消息，让响应方提前获得静态密钥信息，省掉最后的第五条消息。作者没有掩饰交换条件：四消息路径不再保护发起方的凭据身份。这里说的是待讨论的协议选项，不是发生过的泄露事故，也没有证据表明运营网络采用了它。

28 日提交的 01 版保留主流程，却删掉了上述变体。第 3 节把 message_1、message_2、message_3、message_4_KEM 和 message_5_KEM 列为五条必需消息。这并不能证明四消息 KEM 握手在技术上永远不可行，更不能替工作组推断删除动机。可核实的新闻事实只是：同一份工作组草案从“主流程加一个明示隐私代价的捷径”，变成了不再提供该捷径的文本。五消息架构并非 9 月才首次提出。

为什么第五条不能随手当作冗余？KEM 静态私钥的持有者必须先收到针对其公钥封装的密文，随后才有材料证明自己握有对应秘密。草案说，这可能增加最多一个往返。第四条消息承载响应方的密钥确认，第五条则把发起方的确认交给响应方。发起方在接收第四条并构造第五条后可以导出应用密钥；响应方要等到核验第五条后才能做同样的事并发送受保护应用数据。若监控面板只写一个“握手完成”，却不区分两端，就可能把响应方尚未得到的认证结果提前记成事实。

身份保护还取决于本地信任判断。01 版要求发起方在第三条消息发送自己的加密凭据之前，按本地政策验证并接受响应方的凭据。00 版也有这一要求，所以不能把它写成此次修订新增的保障。凭据的签名或格式有效，不等于对方就是预期的通信对象；加密、接受谁的身份、以及最后完成双方认证，是三个不同的决定点。

编号与算法也不能混为一谈。00 版分别提议 COSE 中的 ML-KEM 算法值、EDHOC 密码套件值和认证方法值。01 版的 IANA 章节只保留方法类型建议值“5”，并引用后量子 KEM 表示及 LAKE 套件的其他草案。删去本稿中的注册提案，不等于那些提案已获批准；建议值也不是正式分配。01 版强调此认证方法不绑定某一种 KEM，只有以合适的后量子 KEM 实例化时，才能声称抗量子认证。

因此，运营方若评估受限设备的升级，不能只比较三条、四条还是五条消息。应核对第一条是否暴露身份、实际协商的 KEM 和套件是什么、第五条未到时响应方如何标记会话、以及中止握手留下怎样的状态。这是 Daniel Kade 从草案提出的验收问题，不是 IETF 新设的强制日志制度。现有一手材料没有给出部署率、延迟测量或真实攻击案例。

来源