摘要

  • HPKE 工作组继任草案第 05 版于 9 月 25 日提交；IESG 于 26 日发起批准表决并将其列入 10 月 8 日会议。目前状态仍是评估中，拟取代 RFC 9180 不等于已经取代。
  • RFC 9180 的 Auth、AuthPSK 分别使用 0x02、0x03；新草案只定义 Base、PSK，并把那两个值标为保留。这一取舍在第 04 版已经存在，不能说是第 05 版突然删去。
  • 新草案拟更新 IANA 注册表引用，却明确保留供 RFC 9180 使用的 KEM Auth 字段与既有编号。注册表不能代替应用级模式与身份保证的核验。

一次加密测试通过，未必证明应用原来要求的发送方身份保证还在。HPKE 的继任草案进入 IESG 表决阶段，正把这个通常藏在接口名称背后的问题推到台前。RFC 9180 既描述向接收方公钥加密，也描述把发送方的非对称密钥纳入认证的模式；新文本想成为核心规范的后继，却没有把后一组模式纳入自己的模式表。标准文献的接力与现有应用的能力接力，不是同一件事。

具体差别可以用一个字节写下。RFC 9180 给 Base、PSK、Auth、AuthPSK 依次分配 0x00、0x01、0x02、0x03。新草案第 05 版表 1 只定义前两项，后两项写作“保留”。附录一方面说两份文本共有的行为应保持一致，另一方面明列 Auth 与 AuthPSK 被移出。这里的“共有”是限定词：它保证共同部分的兼容目标，不承诺新文本继续规范旧文本的全部接口。PSK 模式仍可证明某方持有预共享密钥，但这不是旧 Auth 模式用发送方静态私钥表达的同一种身份主张；“新 HPKE 不再有任何认证”同样是错读。

时间线也很重要。第 04 版早已采用相同的保留值安排，9 月 25 日上传的第 05 版不是这一变化的首次公布。新的新闻事实在 26 日：IESG 创建批准选票，状态转为 IESG Evaluation，并将文件排入 10 月 8 日电话会议。查询时仍有投票意见未齐，IANA 也因版本变化需要重新审查。草案题头的“取代 RFC 9180”带有“若获批准”的条件；现在没有一份已生效的继任 RFC 可据此宣布旧功能失效。

负责陪同该文件进入审议的 Martin Thomson 在三月的说明中承认了取舍。他说，原规范中的认证模式部署有限，而且目前设计形式尚缺适合的后量子支持，因此工作组勉强决定本轮先不保留；同时也明确说有人仍依赖这些模式，把安排称为暂缓而非弃用，并留待以后研究恢复。那是工作组进程中的定性说明，不是用户数量审计，更不能推导出旧模式存在已知漏洞或已经被禁用。

IANA 一节揭示了另一层现实。草案准备在获批后替换相关注册表对旧 RFC 的引用，但既有 KEM 编号与注册内容不变。KEM 模板中的 Auth 布尔字段专为 RFC 9180 的 AuthEncap()、AuthDecap() 接口保留，新草案明说自己不使用这个字段。这使旧能力仍可被注册表表达，却不意味着任何特定应用正调用旧接口，更不意味着其对等端已经准备好切换。算法编号、实现能力、线上协商和产品的身份承诺，必须分别查证。

Daniel Kade 的建议不是一纸全面迁移令，而是按应用建立明确决策：找出实际调用的模式和 RFC 版本、接收方期望验证的身份性质、对等实现接受的模式、上层协议是否另行提供认证，并用双方参与的测试确认结果。如果确实依赖旧 Auth 路径，就明确保留并管理它；如果要改变保证方式，就由负责该应用的人批准新设计。这是一种编辑性的运营建议，不是 IETF 在此草案中规定的强制记录。避免的不是“使用旧标准”本身，而是只看到文档引用更新，便以为安全承诺也自动完成了交接。

来源