摘要

  • RFC 9955 是 IETF 于 2026 年 7 月发布的信息类 RFC。它没有规定一种具体的混合签名组合器，而是区分混合不可伪造性、弱与强不可分离性、同时验证、向后兼容、可证明组合、性能与审批便利等目标；这些目标并不总能同时成立。
  • 发送方生成同一份混合签名后，检查全部组件的新验证器可能获得混合安全属性，只检查一个组件的旧验证器却没有获得相同保证。以“已生成多少份混合签名”衡量迁移，会把供给侧能力误写成接收侧事实。
  • 关键决策点应生成一份不含秘密的混合验证回执，记录对象、组合方式、逐组件结果、混合意图痕迹的位置、密钥用途、验证器版本与策略、审批范围、接收群组以及兼容例外的到期时间。这是本文提出的本地运行做法，不是 RFC 9955、IETF 或 NIST 的新增要求。

两个“有效”之间差了什么

验证器通常把复杂过程压缩成一个布尔值：有效或无效。对于单算法签名，这个布尔值已经省略了密钥来源、证书路径、策略版本与判断时间。到了混合签名，它还会省略一个更根本的问题：到底检查了几个组件？

设想一个软件发布包同时携带传统签名与后量子签名。构建系统完成了双签，发布平台便把迁移进度记为百分之百。新设备要求两项都成功；旧设备为保持兼容，只校验传统组件。两者面对相同字节，都会报告成功。若统计只看发送端，它们便被算作同一种成功。若统计看决策端，就会发现两种不同的信任承诺。

RFC 9955 把向后兼容明确称为验证属性。发送者可以完整生成混合签名，接收者仍能依内部策略或实现只验证一项。于是，安全属性不是只附着在文件上的静态标签，而是在每一次接受决定中被实际执行。

这份 RFC 属于 IETF 文档流、体现 IETF 共识，但类别是 Informational。它没有选定具体组合器，没有要求某个行业迁移，也没有采取 IANA 动作。它的作用是给设计者和实施者一张谱系图：所谓“混合”包含多项彼此独立、甚至互相冲突的目标。

治理问题并非如何把这张图重新缩成“支持/不支持”两格，而是如何保存每一个关键验证点落在图上的位置。

混合意图放在哪里，责任就落在哪里

RFC 9955 所说的 artifact，是移除某个签名组件后仍然留下的混合意图痕迹。这个痕迹可能在签名内部，可能在证书或算法协商中，也可能只是写在被签消息里的标签。三种位置把检测责任交给三套不同机制。

若痕迹在签名中，算法级验证可以直接处理。若痕迹在证书或协商里，安全论证必须延伸到协议与证书链。若痕迹在消息里，应用策略必须被允许读取它，并知道如何让它影响结果。

最后一种情况尤其值得警惕。消息的真实性依赖签名，验证器却要从消息内容得知“这里本应有混合签名”。这形成一种循环依赖。痕迹可能足以让事后调查员看出组件被剥离，却不一定让当时的密码学验证自动失败。

这正是弱不可分离性的边界：分离后仍有痕迹，但单个组件可能继续验证成功。强不可分离性则要求从混合签名中拆出的组件不能独立成为有效签名。再加上同时验证，正常验证器就不能在只确认一项后提前宣告成功；它必须先得到全部组件的结果。

因此，“拼接式”“嵌套式”“融合式”这些名称仍不足以证明属性。RFC 9955 展示了同一大类方法可以把痕迹放在不同位置。采购书或架构图若只写“混合签名”，没有写痕迹位置和验证行为，便没有说明真正的控制面。

兼容不是免费通行证

保留旧验证器往往有现实理由。工业设备、根证书、法律档案、政府系统和关键基础设施的更新周期可能以年计算。后量子迁移若等到最后一台旧设备退役才开始，可能错过必要的准备期。

但兼容必须被当作一次可计价的保证让渡。RFC 9955 指出，向后兼容与强不可分离性天然互斥。强不可分离意味着拿掉一个组件就必须失败；旧验证器要继续工作，恰恰需要只凭它理解的传统组件也能接受。RFC 还指出，当兼容真的被执行——验证器确实跳过一项——这次验证也就不再具有混合不可伪造性的完整性质。

同一文件由此会跨越不同的安全边界。新验证器的成功不能自动覆盖旧验证器的决定。管理层若只看到“双签覆盖率”，可能误以为整个组织已经获得相同保证，实际最重要的一批接收端仍依赖单项算法。

诚实的兼容策略至少要回答四个问题：哪些验证器属于例外群组；它们放弃了哪种属性；谁有权接受这一风险；例外何时结束。缺少其中任何一项，临时通道都容易变成永久入口。

密钥复用把边界推向系统之外

组件剥离攻击不一定发生在原定接收者那里。若同一把组件密钥还被另一套应用、另一种协议或另一条证书路径接受，攻击者可能把从混合对象中得到的组件交给完全不同的验证器。

在主应用中写下“必须双项通过”并不能保护那些外部验证点。RFC 9955 提到的缓解方法，是限制组件密钥复用，并通过证书中的允许用途约束签名者和验证者。但文档同时强调：这是一项策略要求，不是密码学保证。

这一区分决定审计范围。密码学保证由构造本身强制；策略保证只在所有相关参与方一致执行时成立。若组织不知道一把公钥还在哪些系统里受信，就无法证明“不复用”已经成为运行事实。

因此，混合迁移不能只维护算法清单。它必须把公钥标识、证书、允许用途、协议、验证器版本、应用负责人和策略修订串成同一个查询面。任何接受同一组件密钥的地方，都属于控制边界。

“策略镜像”在这里不是比喻。纸面写着专用密钥，运行系统却在别处接受它，镜子反射出的就不是政策宣称，而是实际权力。

审批轴与安全轴不能叠成一条

后量子项目还面对认证与审批压力。复用已批准的算法模块，能缩短采购和部署时间；把不同组件融合得更紧密，则可能需要新的安全分析与批准。RFC 9955 刻意把“需要何种审批”的谱系与“提供何种不可分离性”的谱系分开。

这一步非常重要。把组件当黑盒调用的包装器，可能更容易保留各模块原有的批准状态，却不会因为行政便利而自动拥有同时验证或强不可分离。融合构造可能提供更明确的一体化失败边界，却带来新的审批成本。两者都是事实，没有任何一个可替代另一个。

NIST 的后量子密码 FAQ 说明，双签验证要求所有组件都成功；现行标准可在至少一个组件算法获 NIST 批准的情况下容纳双签。FIPS 204 则单独标准化了 ML-DSA。这些表述都有边界。它们不能被延伸成“整套混合保证已经获批”，除非说明批准覆盖哪个算法、哪个模块、哪个组合器以及什么运行行为。

治理者要允许项目选择较容易审批的方案，也要让由此增加的策略依赖、密钥范围和旧系统例外清晰可见。合规标签是证据的一部分，不是最终结论。

一份验证回执应当记什么

签名对象不需要再复制一遍。缺失的是接受决定的上下文。混合验证回执应在会产生真实后果的边界生成，并绑定以下信息：

  1. 被签对象的摘要、使用场景、预期的混合构造及版本；
  2. 各组件算法、非秘密的公钥标识，以及实际验证过的证书或来源链；
  3. 每一处混合意图痕迹的位置，以及当前验证器是否真的检查；
  4. 策略要求的组件结果向量、实际逐项结果和最终综合决定；
  5. 所依赖的是弱不可分离、强不可分离还是同时验证，不能从产品名称倒推；
  6. 验证器软件构建号、配置哈希与策略修订；
  7. 组件密钥用途限制，以及负责执行限制的完整系统群；
  8. 按具体算法或模块记录的批准、认证状态，不向整套保证外推；
  9. 接收端群组、任何旧系统例外、责任人和到期时间；
  10. 失败与部分结果的处理方式，尤其是能否在另一项完成前影响决定；
  11. 决策时间、证据保留期限，以及长期对象何时必须重验；
  12. 无法复现保证时，有权拒绝、隔离或撤回接受的角色。

回执必须不含秘密。它存储摘要、版本、有限标识和受保护日志的引用，不存私钥、签名随机数或敏感正文。它也不改变组合器的数学强度。它只阻止一个过度压缩的“有效”状态被升级成未经证明的制度承诺。

怎样验证迁移真的发生了

测试应从接收群组出发，而不是从算法列表出发。选取同一套经审查的签名样本，让每种实质不同的软件构建与策略组合执行。测试要覆盖缺少任一组件、任一组件失败、混合意图痕迹被改动、证书链变化，以及组件密钥在其他上下文被接受的尝试。

输出不能只有成功率。它要显示哪些检查实际发生、发生顺序、使用的策略与最后决定。随后再把证据与机构准备公开的句子逐字对照。

“发送者均已双签”是一项可验证陈述。“所有关键接收者均校验双项”是另一项。“构造具有强不可分离性”是第三项。“某组件模块获得批准”又是第四项。最低初始规格要求把它们分别证明，而不是用“量子安全”一次性包裹。

如果测试发现旧群组，这不是项目失败。它提供了一个可管理对象：缩小范围、隔离密钥、安排预算、指定负责人并设定退出日。没有回执，旧群组只是无人看见的兼容理由；有回执，它才会成为会到期的治理决定。

边界

本文没有报告真实产品缺陷、签名剥离事件、伪造、合规失败或运营事故。来源提供的是标准与设计分析，不是市场部署率。强不可分离与同时验证也不是每个场景的唯一正确选择；它们会与兼容、性能、可组合证明和审批成本冲突。

验证回执不能修复脆弱算法，也不能预言未来密码分析。它能保留一项更朴素的事实：当机构说“我们接受了这份混合签名”时，究竟是谁检查了什么。

来源