摘要

  • 正在 IESG Evaluation 阶段的 draft-ietf-hpke-hpke-05 定义 Base 0x00 与 PSK 0x01，并把 RFC 9180 曾用于 Auth、AuthPSK 的 0x02、0x03 标为保留。
  • 规范可以划定下一套共同规则，却无法替每个应用证明旧 API、旧配置、旧对象与旧对端已经退出；关闭兼容面需要运行证据，而不是引用表格。

一个保留值能说清很多事，也会被误解成说清了一切。

它说明下一版共同规范不再定义这个模式，不应为新实现继续扩展它。它没有扫描任何生产进程，也没有检查归档对象是否仍要通过旧路径解密，更不知道某家合作方的设备何时升级。

因此，0x02、0x03 在文档中变成 RESERVED，是标准状态收据；“我们的环境已经没有 Auth/AuthPSK”则是运行状态结论。两者不能用同一份证据签字。

先守住文档状态

Datatracker 显示，修订版 05 发布于 2026 年 9 月 26 日，是 HPKE 工作组的活跃 Internet-Draft，目标为 Proposed Standard，已提交 IESG，目前处于评估阶段，并列入 10 月 8 日 telechat。IANA 一栏仍显示版本变化后需要重新审查。

草案页首写的是：若获批准，它将取代 RFC 9180。当前还不能省略这四个字。冻结证据没有最终 IESG 决定，也没有新的 RFC 编号。

模式删除也不是 05 版突然增加的新闻。7 月的 04 版已经保留相同两个取值，并在差异附录中列出 Auth 与 AuthPSK 的删除。9 月版本的意义，是这套设计正在更成熟的审议位置，而不是删除动作刚刚发生。

RFC 9180 来自 IRTF 流，状态为 Informational；候选替代文本寻求 IETF Proposed Standard。流程可以提高下一共同契约的权威与清晰度，却不会自动改写旧软件的硬盘和内存。

“向后兼容”有一个明确的集合边界

修订版 05 的附录 A 说，对于两个文档都规定的功能，新文本希望与 RFC 9180 保持相同行为。Base 和 PSK 属于交集。

Auth 与 AuthPSK 不再属于交集。RFC 9180 给它们 0x02、0x03，并定义使用发送方静态密钥的设置函数；候选规范保留编号、移除模式。把整次变化笼统描述为“完全向后兼容”，恰好掩盖了真正需要迁移的部分。

即使在交集内，兼容测试也必须标注范围。一组 Base 测试向量一致，只能证明所用算法套件、输入与实现得到了相同结果。它不能证明所有调用方已改用新 API，不能证明旧进程已重启，也不能证明租户例外或延迟队列已清空。

可审计的测试条目应包含：文档修订版、模式、套件、库构建、入口函数、密钥角色、应用画像与对端。只有写出这些维度，兼容才是可以执行的判断，而不是宣传用词。

通用密文并不自带完整资产清单

HPKE 是被上层协议嵌入的密码构造。候选文本把 enc、psk_id 等非私密参数如何传输留给应用；当接收方有多把密钥时，如何选出正确密钥也由应用决定。

模式与密码套件来自实现和应用上下文。不存在一个适用于所有产品的统一 HPKE 信封，让运营者只看一个明文头字段就能完成全网模式盘点。

有的画像通过不同 API 函数选择模式；有的画像在版本号或对象类型里固定模式；还有的系统用配置或协商结果决定。只抓 ciphertext 可能看见流量，却无法知道哪条设置路径产生了它。只搜源码可能找到旧函数，却不能证明它曾被启用。

相反，主仓库搜不到也不能下结论。静态链接、vendored 依赖、硬件模块、灾备镜像、长时间休眠的 worker 与旧容器都可能不在那次搜索里。资产范围本身必须成为证据。

退役应拆成八张收据

第一张是规范收据：当前草案、流程状态以及拟删除的精确行为。第二张是画像收据：哪个应用协议用何种方式选择模式。第三张是二进制收据：服务实际装载哪个构建与哈希。第四张是配置收据：每类操作、对象和对端允许哪些路径。

第五张是使用收据：某次发送或接收实际选择了什么。第六张是存量收据：队列、备份、归档与延迟对象是否还需要旧读路径。第七张是对端收据：目标对端是否真正完成替代画像的互操作。第八张是结果收据：解密之后的应用动作是否完成。

版本升级不能代替这八张收据。新包可能已安装，旧进程却仍在内存中；进程可能已重启，租户例外仍然开放；例外可能从未使用，但历史对象仍需旧解码器；canary 可能成功，而低频对端仍不兼容。

正向证据同样不能放大。源码中存在 Auth 函数，只证明能力；配置允许 Auth，只证明许可；旧对象能解密，只证明密码步骤成功。它们都没有自动证明发送者的业务权限、消息新鲜度或下游结果。

一个个人草案展示了“分支”，没有展示“共识”

draft-ms-hpke-auth-modes-01 提议把 AuthPSK 作为严格扩展重新加入。它恢复 Auth 的计算机制作为构建块，但不单独恢复 Auth，理由是单独的经典 Auth 无法提供量子抗性。

Datatracker 对其地位写得很清楚：这是个人 Internet-Draft，任何人都可提交，不代表 IETF 背书，也没有正式标准流程地位。它不能被写成已经批准的迁移方案。

不过，它证明了一个结构事实：从共同核心删除某项功能，不等于技术上禁止任何人另建兼容集。若这项扩展将来推进，它仍需自己的安全分析、应用绑定、实现、测试和采用证据。

HPKE 与 JOSE 邮件列表上的讨论也只能按这个层级使用。参与者争论签名、经典隐式认证、密钥加密与后量子组合，说明问题仍在讨论；邮件不是工作组共识，更不是部署统计或事故证明。

PSK 的“发送方认证”需要外部身份绑定

候选核心仍给 PSK 模式一项发送方认证属性。其密码学含义是，建立正确上下文的一方持有预共享密钥。

一把 PSK 可以由一个进程独占，也可以被一个集群、多家设备或多个环境共同持有。谁有资格拿到它、能为哪项操作使用、何时轮换、是否跨域复用，都由上层密钥治理决定。密钥持有证明不会自动变成个人身份、公司授权或不可否认性。

草案还明确列出 HPKE 的非目标：它不负责应用层重放与降级防护，不保证消息顺序和丢失处理，不隐藏明文长度，不补救劣质临时随机数，也不在接收方私钥日后泄露时提供所需的前向保密。

所以，从 Auth 迁到 PSK 不能只用“解密成功”验收。应用必须先写清要证明的主体、权限、新鲜度和业务结果，再检查 PSK 的分发与绑定是否真的承载这些语义。

发送路径能先停，接收路径不能盲删

停止生成旧对象通常早于停止读取旧对象。邮件、遥测包、延迟任务、重试队列、备份和合规归档都有自己的存活周期。

如果接收方在最后一个对象到期前删除旧密钥或解码器，标准迁移会变成数据可用性事故。如果为了保险无限期保留旧路径，又会形成没有负责人、没有期限的长期攻击面。

存量台账至少应记录：对象格式、创建窗口、画像版本、密钥标识、保留期限以及替代读路径最后一次成功验证。历史系统若没保存足以确定模式的元数据，应把它记为未知风险，而不是依据密文外形猜测。

删除密钥、格式元数据和恢复工具属于不可逆步骤，必须单独授权。停止新写入和执行永久删除不是同一个变更窗口。

标准给出目标，观测证明切换

Heng Lu 的最小初始规范、局部未来决策与运行代码优先原则，为这次迁移提供了一个合适的分析框架：文档可以定义共同层；后续变化要通过实现、验证、部署与使用，才会进入某个参与者的现实兼容集。

这不是否定标准。相反，它要求标准只承担自己能证明的作用。候选规范收缩 HPKE 核心，运营团队则用本地、对端与结果证据完成真实切换。

一份可信的完成报告必须限定范围：盘点了哪些画像和构建，覆盖了哪些流量与休眠路径，迁移或销毁了哪些对象，哪些例外已关闭，哪些对端通过测试，以及多长时间未再观察到旧路径。范围之外仍应写“未知”。

来源