摘要

  • 2026 年 9 月 24 日，IESG 批准 draft-ietf-jose-hpke-encrypt-22 按 Proposed Standard 发布。它目前仍是 Internet-Draft，既不是已发布 RFC，也不是部署证明。
  • Integrated Encryption 由 HPKE 直接为唯一收件人加密明文；Key Encryption 则由 HPKE 保护共享内容加密密钥，可在同一 JWE JSON 中并列 HPKE、ECDH 或 RSA 收件人。
  • 草案要求至少一个收件人验证成功，却把“一个即可”还是“全部必须成功”交给应用决定；共享 CEK 的整体机密性还受最弱收件人算法限制。

明文出现以后，问题才刚开始

设想一份 JWE 同时发给在线业务、合规保管方和灾难恢复系统。在线业务那条路径成功取得内容加密密钥，密文认证通过，库返回明文。就密码处理而言，这次成功真实而且有用。

但恢复系统是否属于强制收件人？合规保管方所用算法是否已经越过退役期限？信封里有没有一条从未获批的额外路径？明文本身不会回答这些问题。若系统只记录“解密成功”，原本具有三个结果的收件人集合就被压成了一个过于粗糙的绿色状态。

9 月 24 日的标准进展使这条边界具有现实意义。IESG 宣布批准 JOSE 工作组第 22 版 HPKE/JWE 草案，准备作为 Proposed Standard 发布。该决定证明标准流程走到一个明确节点，却不证明任何产品已经实现、不证明测试向量通过、不证明密钥配置正确，也不证明某项企业分发规则已经执行。RFC Editor 流程尚未完成，因此它也不应被写成已经发布的 RFC。

两种模式产生两套证据结构

Integrated Encryption 是单收件人直接路径。HPKE 直接加密明文，没有独立 CEK，所以 enc 必须缺席。受保护头中的 alg 选择一套完全指定的 HPKE 算法；ek 不得出现；收件人必须恰好一个。JWE Encrypted Key 承载 HPKE 封装秘密，而通常存放 JWE IV 与认证标签的位置为空，因为相关 AEAD 操作已经包含在 HPKE 内部。

Key Encryption 则保留 JWE 的内容层。发送方生成随机 CEK，按照 enc 加密一次正文，再用 HPKE 为某个收件人加密 CEK。该收件人的 JWE Encrypted Key 是 CEK 的 HPKE 密文，ek 则保存 HPKE 封装秘密。Recipient_structure 作为 HPKE 的 info 输入，把 JOSE 上下文、内容加密算法以及可选应用上下文绑定进密钥派生。

这层间接性带来多收件人能力。在 JWE JSON 序列化中，HPKE 收件人可以与 ECDH-ES+A128KW 或 RSA-OAEP-256 收件人并列。每条路径分别保护同一把 CEK，正文只需加密一次。

迁移由此可以分阶段进行，恢复密钥也不必复制整份密文。但相同便利也意味着：信封的安全状态不能用其中最新、最强的一条路径代表。

“至少一个”只是协议底线

第 22 版的解密流程没有掩盖这个差异。存在多个收件人时，应由应用决定哪些收件人必须验证成功。有些场景允许任意一个成功；另一些场景要求所有指定收件人都成功。共同协议只规定底线：至少一条路径必须成功，否则 JWE 无效。

对于 JWE JSON，处理器还要向应用返回每个收件人的成功与失败结果。这个结果向量不是调试附属品，而是本地策略作出结论所需的输入。

假设 A 通过 HPKE 成功，B 因轮换不完整而失败，C 通过旧算法成功。库可以得到明文。只要求 A 的应用可以接受；要求 A 与 B 的应用必须拒绝；禁止 C 所用算法的应用，也可以在 C 成功的情况下判定整个对象不合格。密码字节没有变化，控制结论却不同。

草案进一步说明：即使解密成功，只要所用算法不符合该应用场景，应用就应把 JWE 视为无效。标准没有替组织制定统一 allow list；它让实现暴露足够事实，使本地决定可以被审计。

最弱路径可以决定整份内容的风险

Key Encryption 的各收件人最终都指向同一把 CEK。任何一条获准路径只要恢复 CEK，就可以解开公共正文。安全注意事项因此给出直接结论：多收件人场景中，内容安全受用于加密 CEK 的最弱算法限制。

这并不等于所有混合迁移都错误。它意味着不能用最现代的一条 HPKE 路径给整个信封评级，同时忽略另一条仍能交出相同 CEK 的较弱路径。所谓爆炸半径，是收件人集合的属性。

第 22 版的形成过程也说明模式粒度为何重要。标准审查提出问题后，JOSE 进行了第二次工作组 Last Call，范围仅是删除 HPKE-4-KE 与 HPKE-6-KE。这两个 Key Encryption 标识符不再出现在第 22 版中，对应的 Integrated Encryption 标识符 HPKE-4 与 HPKE-6 却仍保留。资产清单若只写“支持 HPKE”，就会漏掉真正变化的控制点。

草案还不建议同一 KEM 密钥对并行用于多个 HPKE 模式或套件，也建议不要让同一密钥跨越 HPKE 与非 HPKE 算法。审计记录因而需要把收件人、模式、套件、密钥身份与授权用途连在一起，不能只留一个友好名称。

Heng Lu 对现实层与符号层的区分在这里很实用。IESG 批准是标准流程事实，alg 是线路格式事实，某个收件人成功是密码处理事实，收件人名单与“一个还是全部”是组织控制事实，实际应用结论则是运行事实。前四项不能自动替代第五项。

来源