Summary

  • draft-ietf-cose-hpke-27 于 9 月 12 日发布，目前仍处于区域主管跟进阶段；它是标准轨道互联网草案，不是 RFC，也不是已获批准的部署配置。
  • 受保护的 psk_id 会选择 PSK 模式；缺少该字段时默认采用 Base 模式。后者能把数据保护给指定收件方，却不在 HPKE KEM 层证明发送方身份。
  • kid 指向收件方密钥，并不标识发送方。Daniel Kade 建议保存一份不含 PSK 和明文的认证—授权收据；这是编辑分析，不是 IETF 的规范要求。

“打开成功”只回答了部分问题

第 27 版草案在 9 月 12 日上线。Datatracker 历史显示，文件已提交 IESG，并处在 AD Evaluation::AD Followup。这一版把随机数要求说得更明确：HPKE 必须使用密码学安全的随机源；在 Key Encryption 模式中，内容加密密钥也必须由密码学安全的随机数发生器产生。

这是一项实质性文字收紧，但不是标准已经完成。当前页面仍可能更新，IANA 编号尚以假定值出现，未来 RFC 是否以及如何发布都没有定论。眼下能够确定的是一种协议边界：解密成功不等于发送方身份已经被验证。

AEAD 中的“authenticated”容易造成误读。它表示密文和关联数据在派生出的对称密钥下通过真实性校验，并不表示任何知道收件方公钥的人都因此成为一个有姓名、有权限的发送者。Base 模式让私钥持有者能够解开对象，却没有在 KEM 中加入发送方认证。

加密布局和认证模式不是同一个开关

草案给出两种布局。Integrated Encryption 在 COSE_Encrypt0 内直接用 HPKE 保护明文，只服务一个收件方。Key Encryption 则先用内容加密密钥保护正文，再让 HPKE 在收件方层包裹这把密钥，因此可以支持多个收件方。

每个新增的 COSE 算法标识都绑定一个完整的 KEM、KDF、AEAD 组合，也绑定它应当用于 Integrated 还是 Key Encryption。这样做可以防止实现方随意拼接组件，或者把某一层的标识拿到另一层使用。

发送方认证模式却由另一个字段决定。受保护头部存在 psk_id 时使用 mode_psk；不存在时使用 mode_base。草案还特别说明，认证模式并未显式包含在密码套件标识中。

因此，两份采用同一算法编号的对象可能表达不同的信任事实。PSK 模式证明发送者持有外部提供的共享密钥；Base 模式不作这项证明。若日志只记录算法编号，就漏掉了真正选择认证路径的输入。

kid 解决的是收件方选钥

草案建议使用 kid 明确发送者所选择的收件方静态公钥。收件方可以据此从多把私钥中找到对应的一把。这对轮换和多代密钥并存很有用，但方向不能弄反：kid 识别的是接收目标，不是消息作者。

规范假定发送方已经持有收件方公钥，并把公钥分发机制留在范围之外。应用必须自行回答：这把公钥来自哪个目录，属于哪个租户，何时失效，又是否被复制到了错误的环境。密码算法会忠实保护输入；它不会纠正组织层面的选钥错误。

psk_id 也不是 PSK 本身。前者必须放在受保护头部，后者作为外部输入，绝不能写进 COSE 对象。PSK 模式的成功意味着对端持有共享秘密，却不会自动把该秘密映射成某个人、某个仍在岗的服务，或某项业务权限。当前 HPKE 草案还警告，PSK 必须有足够熵；低熵口令不能靠换一个受保护标识就变安全。

绑定上下文不等于制定授权规则

COSE 的受保护头部和外部关联数据可以让应用把上下文纳入密码运算。Key Encryption 使用确定性编码的 Recipient_structure，其中包括紧邻下一层的算法、收件方受保护头部以及可选的额外信息。这能缓解层与层之间的算法替换风险。

但机制只能保护应用写入的内容，不能替应用决定该写什么。租户、操作用途、策略版本、有效期和请求编号是否必须出现，仍取决于具体配置。一个上下文为空的对象可能编码合规，却不足以支持本地授权。

HPKE 自身定位为低层机制。除有序上下文提供的有限性质外，重放、算法降级、消息丢失和新鲜度都要由嵌入它的协议处理。单次对象被再次提交时，密码校验可能再次成功；避免同一命令执行两次，需要应用维护状态。

分离密文还会产生覆盖范围问题。COSE HPKE 草案提醒，后来套上的签名或 MAC 不会自动覆盖外置的密文字节，实现方必须另外确保其完整性。审计若只留下“签名有效”，却不写明签名覆盖了什么，结论就大于证据。

Base 模式不是缺陷，而是一种政策选择

匿名但保密的投递可以完全合理：举报入口、公开收件箱，或已经在另一层完成认证的系统，都可能允许任何人向收件方加密。草案也明确列出 COSE_Sign、COSE_Sign1、COSE_Mac 和 COSE_Mac0，作为补充认证的办法。

风险来自把一种模式的成功理解成另一种模式的承诺。PSK 模式也不是万能答案。一把共享密钥可能代表设备、设备组、服务账号或多人班组；持有它不自动决定该持有者能做什么、授权何时到期、离职或退役后如何撤销。

真正的治理节点，是密码结果驱动操作的那一刻：网关接收配置，设备执行指令，平台吸收机密报告。系统需要分别回答“数据如何得到保护”“哪个身份或凭证被验证”“哪一版规则允许执行”。

为“为什么接受”留下收据

Daniel Kade 建议为每份被接受的 COSE HPKE 对象生成一份发送方认证收据。它应记录草案或部署配置版本、Integrated 或 Key Encryption、密码套件、实际 HPKE 认证模式、收件方密钥指纹及分发来源。PSK 模式还应记录 psk_id 的单向指纹、非秘密的密钥版本与生命周期状态；Base 模式则写明另外通过的签名、MAC、认证信道或应用身份检查，或者坦率标注“本配置允许匿名投递”。

收据还应绑定受保护上下文配置、重放或新鲜度结果、分离密文完整性结果、授权策略版本和最终处理决定。它不应保存 PSK、明文或与复核无关的身份数据。使用不透明事件编号和摘要，通常足以支持追溯。

这份收据不是草案、RFC 9052、RFC 8937或 IANA COSE 注册表的要求。它是组织在协议之外补上的决策证据。Heng Lu 的《政策之镜》强调不能把机制结果直接抬升为权威；最小初始规范支持只共享必要的边界记录；BTW 的编辑原则则要求把新草案写成可核实的进展，而不是并不存在的事故。

Sources

  1. COSE HPKE 工作组第 27 版
  2. COSE HPKE 第 26 版
  3. Datatracker 当前记录
  4. Datatracker 文件历史
  5. HPKE 第 04 版草案
  6. RFC 9052 — COSE 结构与处理
  7. RFC 8937 — 安全协议的随机数改进
  8. IANA COSE 注册表
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists