摘要

  • 2026 年 9 月 8 日，Datatracker 将 draft-ietf-lake-edhoc-psk 推进到“WG Consensus: Waiting for Write-Up”，第 09 版也在同日提交；它仍是互联网草案，并非 RFC，也尚未获得 IESG 批准。
  • 新版明确规定，一个 ID_CRED_PSK 可以检索出一套或多套候选 PSK 及相关凭据；响应方逐个尝试，直到 CIPHERTEXT_3B 通过认证解密或候选耗尽。
  • 线上传输的标识依然紧凑，但只记录该标识已经不足以说明究竟是哪一套本地凭据完成了认证。
  • Daniel Kade 建议记录候选集合版本、所选非秘密凭据版本和尝试结果；这是编辑分析，不是草案提出的强制要求。

变化发生在响应方内部，而不是报文表面。发起方在 EDHOC 第三条消息的受保护部分放入 ID_CRED_PSK。它可以采用很短的 COSE kid。响应方收到这个值后，才在本地凭据存储中完成检索。线上的一个值与线下的多个候选，因此可以同时成立。

第 09 版草案对这条路径给出了清楚步骤：查找结果可以包含一把或多把 PSK，以及处理 EDHOC 所需的信息。响应方先选第一个候选，据此派生 K_3 与 IV_3，再对 CIPHERTEXT_3B 做 AEAD 验证；失败后可以换用下一个候选。只有所有候选都失败，才按处理错误或篡改处置。某个候选验证成功，证明对端掌握了该候选对应的 PSK 并主动参与了交换。

这不是措辞上的微调。第 08 版把标识描述为检索“正确的 PSK”，并建议以唯一或随机方式标识密钥，从而避免歧义和多密钥试算。官方版本比较显示，第 09 版保留了唯一或随机标识的建议，却把多候选从应当避免的状况变成了明确的处理分支。唯一映射仍是更简单的情形，但不再是唯一被描述的情形。

被选择的是凭据上下文，不只是一串密钥字节

把查找结果简称为“几把钥匙”会遗漏重要边界。草案要求候选同时带有 PSK、CRED_I、CRED_R 以及协商套件所需的处理信息。发起方和响应方凭据必须彼此不同，以缓解反射与错误绑定问题；候选使用的哈希上下文也必须适配所选密码套件。响应方实际尝试的是完整认证上下文，而非一组可以任意互换的字节串。

RFC 9528定义的基础 EDHOC 已经把紧凑凭据引用与引用所指向的凭据分开。RFC 9052中的 COSE kid 本来就是识别提示，而非全球唯一名称；RFC 8392则给出了关联声明可采用的表达形式。PSK 扩展的多候选路径进一步放大了这一区别：短标识负责把处理引向本地集合，却不独自证明集合中哪一项被接受。

这里也不能套用“密码猜测”的比喻。第 09 版要求外部 PSK 至少具有 128 位熵，长度也至少为 128 位，并明确排除从密码或其他低熵输入派生共享秘密。候选是预先配置、恰好共用一个查找句柄的认证上下文，不是让响应方搜索弱口令的字典。

可用性收益来自受控重叠

草案没有规定为何要保留多个候选。密钥轮换、新旧配置短暂并存、紧凑标识空间在不同分区内复用，或恢复流程暂时保留旧上下文，都是合理的运营推断，而不是已有部署事实。当前证据包没有展示任何生产系统已经采用多候选映射。

这些安排可以避免受限链路传输更大的身份对象，也能让轮换不必在同一瞬间完成。但代价是控制权转移到响应方的查找表：候选的成员、顺序、退休时间与尝试预算都不会出现在来包中。两个本应一致的响应方，可能收到同一标识、接受同一对端，却在不同位置找到成功候选。

若日志都只留下 ID_CRED_PSK，这两种状态在事后看起来完全相同。运营人员无法据此判断旧凭据是否先被尝试、替换版本是否已生效，或某条回退路径是否仍在承担流量。协议的“认证成功”是真实结果，收到的标识也是真实输入；错误在于把后者提升为它没有提供的唯一凭据证明。

工作组形成共识，并不等于标准已经发布

工作组最后征求意见的通知与评审将第 08 版的评审窗口设在 7 月 1 日至 15 日。LAKE 邮件列表中保存的候选选择讨论提出了验证失败后更换候选等步骤，后来进入第 09 版。

9 月 8 日的 Datatracker 历史记录显示，文件状态从工作组最后征求意见推进到“WG Consensus: Waiting for Write-Up”，Marco Tiloca 被列为文档指导人，问题标签也被清除。当前文档页仍将它列为 LAKE 工作组拟走标准轨道的活跃互联网草案。指导人报告、IESG 审查、可能的新修订、批准和 RFC 发布仍是后续而非既成事实。

保存选择事实，但不要保存秘密

运营记录不需要、也不应包含 PSK 本身。它需要回答一个更窄的问题：这个响应方针对这次查找，接受了哪一版非秘密凭据上下文？

一个合比例的记录可以包括：收到的 ID_CRED_PSK 指纹、候选集合的版本或摘要、候选数量、被选中的非秘密凭据版本、EDHOC 套件与哈希上下文、尝试次数、结果、策略版本和时间。若候选耗尽，同一结构也应表达“没有候选通过”，而不暴露候选内容。延迟与耗尽率可以按候选数量分档聚合，避免产生逐设备的公开身份记录。

这种记录还会让轮换更容易纠偏。成功开始从第一候选移向第二候选，短期内可能说明迁移正在进行；超过退休日期仍如此，则更像陈旧状态。按策略应一致的响应方若报告不同的集合版本，问题也能在事故发生前出现，而不是留给一句含混的“PSK 失败”。

以上审计结构是本文的编辑建议，并不属于第 09 版的规范文字。草案负责规定密码处理，部署方仍需决定留存与隐私边界。真正需要避免的是：查找已经变为复数，治理记录却继续假设它是单数。

来源