摘要

  • JOSE HPKE 第 22 版以拟议标准项目列入 9 月 24 日 IESG 电话会议议程；公开状态仍是审议中，不能写成已获批或已完成 IANA 登记。
  • 第二轮公众征询要求从“密钥加密”清单撤去 HPKE-4-KE、HPKE-6-KE，理由是 JOSE 尚未登记 ChaCha20/Poly1305 内容加密算法；“集成加密”的 HPKE-4、HPKE-6 仍在草案中。
  • 对采用者而言，声称“支持 HPKE”不足以说明具体可用的 JWE 模式、alg/enc 组合或接收方数量。

先看没有后缀的路径。草案所称集成加密让 HPKE 直接处理明文，只允许一个接收方，而且 JWE 头不得出现 enc：此处不存在另行选定的内容加密算法。草案列出的 HPKE-4 与 HPKE-6 在 HPKE 内部使用 ChaCha20Poly1305，并未因第二轮审议消失。因此，把此次删项概括为“ChaCha 被禁用”，会把范围说错。

有 -KE 后缀的路径另有分工。HPKE 在这里加密的是内容加密密钥 CEK；真正的内容再由 JWE 的 enc 算法加密。JSON 序列化可以把同一密钥分配给多个接收方，也可以混用其他密钥管理方式。草案要求以 ek 承载封装秘密，并把 enc 值放进接收方上下文，使密钥派生与内容算法选择关联。目前这条路径列出六个候选编号：0、1、2、3、5、7 的 -KE 版本，而不再列 4 与 6。

程序变化恰好落在这条接缝。IESG 7 月启动、8 月 3 日结束的第二次 Last Call 明说，删除两个 -KE 选项，是因为 JOSE 没有相应的 ChaCha20/Poly1305 内容加密算法登记；负责的领域主任在 9 月 15 日的第二次投票说明中称，此次重走程序只改这一点。HPKE 内部的 AEAD 与 JWE 外层内容加密算法是不同位置，不能凭名称相似就把注册许可互相借用。

Datatracker 显示该案票数已足以通过，并排入今天的议程；这仍不是最终批准公告。IANA 标记是“OK – Actions Needed”，不是登记完毕，更不是互操作或部署证据。真正需要回答的是：系统准许的是直接加密一份消息，还是替多个接收方包装 CEK？该问题比“有没有 HPKE”更接近产品能兑现的边界。

来源