摘要

  • draft-ietf-jose-deprecate-none-rsa15-06 的 IETF Last Call 将于 2026 年 10 月 9 日结束；文件仍是草案，也尚未改变 IANA 的在线注册表。
  • 草案要求专家分别以 EUF-CMA 审查 JWS 签名与 MAC，以完整 JWE 加密过程的 IND-CCA2 审查密钥管理，以 AEAD 审查内容加密。
  • 明确目标能约束和解释注册判断，却不能证明某个代码库、密钥、参数、配置或线上交换是安全的。

标题之外的长期变化

IESG 于 9 月 25 日启动 Last Call，征求意见至 10 月 9 日。Datatracker 仍将第 06 版标记为推进 Proposed Standard 的工作草案，并注明需要 IANA 审查。邀请评论不是批准，更不是注册表已经执行变更。

RFC 7518 目前采用 Specification Required 程序，由 Designated Experts 在公开审查期后给出意见。现有标准要求他们检查重复功能、普遍适用性、描述清晰度，并对密码学可信度做合理尽职调查。第 06 版没有推翻这套程序，而是给“可信度”装上三个更具体的坐标。

JWS 签名与 MAC 对应 EUF-CMA：即使攻击者可以选择消息并取得有效认证结果，也不应因此为新消息制造出有效结果。JWE 内容加密对应 AEAD：不仅要保护明文机密性，还要保证那些无需加密、却不可被悄然篡改的关联数据具有完整性与真实性。

最关键的一句写在密钥管理部分。IND-CCA2 不是只对孤立的密钥管理算法提出，而是针对由它产生的完整 JWE 加密过程。这意味着证据必须穿过组件接缝。一个强健的原语，若与错误参数、薄弱内容加密、不一致的字段绑定或泄漏差异的错误处理组合在一起，不能借原语本身的声誉替整个系统背书。

标准更明确，判断并未消失

草案使用“有合理理由相信”这样的表述，没有规定唯一证明格式、指定实验室或机械清单。密码算法的证据本来就可能来自形式化证明、公开分析、长期审视和组合论证。专家仍需判断，也可能需要咨询其他研究者。

变化在于，判断有了可审计的对象。申请者与审查者可以具体争论：签名论证是否覆盖 EUF-CMA；JWE 分析是否真的涵盖整个加密过程；enc 方法是否同时处理关联数据。相比一句模糊的“密码学上可靠”，这些问题更容易记录、复核与纠正。

草案也明确，新标准不适用于以 Deprecated 或 Prohibited 状态登记的算法。注册表还承担识别与历史协调功能，因此可以收录不应被常规选择的算法。由此可见，“在表中”从来不等于“适合我的服务”。

注册表之后还有四道证据链

IANA 行项目可以记录标识符、使用位置、实现要求等级、变更控制方、规范和分析文献。它不能说明哪个版本的库真正实现了经审查的构造，也不能证明参数、密钥来源、协商策略、降级防护或一次具体交易的结果。

Heng Lu 的最小初始规范为此提供了公开的编辑视角：独立实现共同需要的安全不变量，可以进入薄的公共层；后续变化是否真实，则要由运行代码和本地采用来证明。EUF-CMA、完整过程的 IND-CCA2 与 AEAD 可以成为公共安全底线，但它们不能替运营方完成部署选择。

因此，一条健康的证据链至少分四层：注册审查说明某种算法是否进入共同命名空间；实现审查说明某套代码是否忠实实现；部署授权说明某个参数与密钥生命周期是否适合具体服务；交易记录说明一次实际交换发生了什么。把四层压成一个绿色标记，正好会抹掉草案试图带来的清晰度。

来源