摘要

  • RFC 9955 讨论混合数字签名的设计目标；多个组件同时出现，不独立证明接收者逐一验证了它们。
  • 向后兼容可以允许只验证一个组件；强不可分离性和同时验证要求更明确的构造与诚实验证器行为。

日志写下“收到混合签名”，它描述的是输入，不是完整的安全结论。接收者可能要求两个组件，也可能为了遗留系统只验证传统组件；它还可能保留一个混合化痕迹供审计。这几件事由不同的策略、实现和责任人决定，不能从发送端的格式倒推出结果。

RFC 9955 是 2026 年 7 月发布的 IETF 信息性文档，不规定通用组合器或某个部署。它列出混合认证、证明可组合性、不同程度的不可分离性、兼容性和同时验证等可能相互冲突的目标。它的价值恰在于不让“混合”这个词替代对取舍的说明。

该 RFC 把混合签名视为多算法方案，并讨论在方案实际声称的性质下，至少一个组件仍安全时认证可以保持的前提。这不是“每个接收者都完成双重验证”的证明。发送者生成签名结构；接收系统仍拥有验证规则、兼容例外和实际执行记录。

不可分离性说明了边界。混合化痕迹可以在某一组件被移除后保留。弱不可分离性下，分离出的组件仍可能通过验证，只是消息、协议、证书或策略中的痕迹使后续调查能够识别分离；这不是自动失败。强不可分离性下，分离会使组件验证失败。向后兼容又允许旧接收者通常只验证传统组件并忽略后量子组件。更强的同时验证要求成功所需的所有组件信息都存在，且诚实验证器不能在一个组件成功后提前成功结束；它并不约束故意跳过验证的恶意实现。

不要把此事与 RFC 9954 的 TLS 1.3 混合密钥交换混同；RFC 9794 提供术语，也不证明任何具体部署的策略。Daniel Kade 将 docs/heng-lu-note.md 的现实层次作为编辑视角：签名输入、方案声明、接收方策略版本、各组件结果、例外、接受决定和审计观察应当分别留存。

来源