摘要

  • RFC 9763 允许申请人在申领新证书时，证明自己控制一张既有证书的私钥；签发机构随后可把既有证书完整字节的哈希写入新证书。
  • 这个关联只说明签发时确认过同一主体的控制关系。它既不强制两张证书共同使用，也不证明两把私钥在当前会话中都已行动，更不替验证方决定接受还是断开。
  • 可追责的迁移必须分开保存登记证明、签发策略、精确证书字节、两条认证路径、协商结果、当前密钥证明和本地授权决定。

事故复盘会上，最容易问错的问题是：“证书里不是已经写着 RelatedCertificate 吗，为什么还会认证失败？”

这个问题把三个时刻压成了一个。申请证书时，一把既有私钥曾经签名；签发新证书时，认证机构曾经写入一项关联；建立连接时，对端还要面对当下收到的证书、当下发生的签名、当下接受的信任锚和当下运行的策略。前两个时刻不能替第三个时刻作证。

RFC 9763 的正式标题是“协议内多重认证所用的关联证书”。它定义 relatedCertRequest 证书签名请求属性和 RelatedCertificate X.509 扩展。这一组合为“两张终端实体证书属于同一终端实体”提供额外保证。标准同时明确提醒：这些机制只表达关系，本身不会产生任何安全功能。

申请阶段有两次不同的私钥动作

设既有证书为 Cert A，新申请的证书为 Cert B。传统密码算法向后量子算法迁移，是 RFC 给出的主要场景。主体希望保留原有证书可用性，同时获得一张采用新算法的证书。

Cert B 的普通申请中包含新公钥。在 RFC 2986 定义的 PKCS#10 模型里，主体对申请信息签名，把主体名称、公钥和属性绑定起来，也展示对相应新私钥的控制。

RFC 9763 另加一项针对 A 的证明。relatedCertRequest 含有四个字段：A 的签发者与序列号、申请时间、定位信息和签名。签名覆盖 DER 编码的签发者与序列号，再拼接 BinaryTime；签名动作由 A 对应的私钥完成。

这里的时间不是装饰。RFC 6019 将 BinaryTime 定义为从 UTC 1970 年 1 月 1 日零时起计算的秒数，不计闰秒。共同格式使签名字节确定，但“多新才算足够新”由认证机构的本地策略决定，RFC 没有规定统一窗口。

因此，审计记录不能只保留一个“fresh=true”。它还要保留申请时间、判断时间、允许窗口和策略版本。否则规则从五分钟改为两分钟之后，旧结论无法重演，也无法判断当时是正常接受还是超窗放行。

认证机构执行的是一条检查链

支持该属性的认证机构必须取得定位信息所指向的 Cert A，并依照 RFC 5280 验证它的认证路径。机构还必须把实际证书中的签发者与序列号和 certID 比较，检查时间是否符合本地新鲜度政策，再用 A 的公钥验证属性签名。

这不是一个模糊的“关系验证”动作。取得证书回答“收到了哪些字节”；路径验证回答“在这组信任锚和策略输入下是否成立”；标识比较回答“是否确为申请中点名的证书”；新鲜度回答“这次证明是否仍在机构接受的时间范围”；签名验证回答“A 的私钥是否对这组申请数据行动过”。

把这些步骤合并为一个绿色状态，会让故障和攻击失去归属。URL 返回了别的证书、路径落到未授权信任锚、时钟漂移、签名无效，所需处置完全不同。

RFC 5280 也没有把路径有效性描述成全球统一真理。信任锚、初始策略和应用约束都是验证输入；算法给出最低有效条件，具体应用仍可进一步收紧。若证书同时包含 key usage 与 extended key usage，两者必须独立处理，实际用途必须同时符合。

完成检查后，机构可以签发包含 RelatedCertificate 的 B。要让扩展有意义，机构只能引用申请中列出的 A；A 必须具有 B 所主张的 key usage 位和 extended key usage OID；机构还应在签发时判断 A 有效。

但 A 与 B 的有效期能重叠多久，仍是订户的责任。如果 A 次日过期，B 的一年有效期不会自动得到一年双证书能力。如果 A 被重新签发，即使主体和公钥相同，只要证书字节变化，新 A 也不会自动成为 B 所关联的那一张。

哈希锁定的是一张具体证书

B 的扩展包含摘要算法标识和 A 整张证书的哈希。被哈希的不是抽象主体名，不只是公钥，也不是“所有由某机构签发、属于某客户的证书”。它指向一次具体签发的完整字节。

这个设计带来一项很强的本地可验证性。验证方收到 A 与 B 后，可以按扩展中的算法对 A 重新计算哈希，再与 B 中的值比较。结果不依赖在线机构临时解释。相同就是相同，不同就是不同。

精确性也揭露资产台账的弱点。许多清单以主体名、设备名或密钥标识归组；一张续签证书可能仍被归入同一条目，却因序列号、有效期、扩展或签名不同而拥有完全不同的哈希。如果运行端部署的是新 A，而 B 仍指向旧 A，管理界面上的“已关联”不代表线上的精确关联成立。

该扩展不应被标记为 critical，因为不认识它的旧实现会因此严重受损；它只能出现在证书链的终端实体证书中。这是兼容设计，不是采用证明。旧客户端忽略非关键扩展后仍可继续处理证书，但它并没有执行关系检查。

哈希相符以后，标准刻意停手

对于支持非复合混合认证的协议端点，RFC 给出的运行时步骤很窄：在收到相应认证材料后检查 A 或 B 中的关系扩展，按指定算法计算另一张证书的哈希，并确认是否相符。

接下来怎么做，标准留在范围之外。一个对端可以要求两次认证全部成功；另一个对端可以允许至少一次成功。CMS、S/MIME 这类由签名方选择提供哪种签名的系统，与 TLS、IKEv2 这类协议内协商场景拥有不同控制面。RFC 5652 提供 CMS 语法与证书结构，RFC 8551 提供 RFC 9763 引用的 S/MIME 证书封装方式；格式本身都不替应用批准访问。

RFC 9763 对边界说得十分直接：关联既不是要求，也不是强制，不要求任一证书必须与另一张共同使用。它只提供保证——两张证书可以共同使用，因为同一主体控制其私钥。

这不是标准遗漏，而是风险归属。认证机构应为登记时的检查和签发时的断言负责。运行端为自己接受哪些信任锚、要求哪些算法、验证哪些签名以及是否继续连接负责。前者不能凭一项扩展接管后者的决定。

登记时控制不等于使用时控制

RFC 安全考虑中的关键分界是两只时钟：混合方案需要在登记时向 CA 提供“同一主体控制所有相关私钥”的证据，也需要在使用时向验证方提供当前控制证据。

relatedCertRequest 的签名证明 A 的私钥参与了那次登记。普通 CSR 的签名在其模型内证明 B 的申请者控制新私钥。扩展保存 CA 对两张精确证书关系的签发断言。日后的每一次会话，仍要让协议要求的私钥真实行动。

如果当前报文只由传统私钥签名，那么旁边放着一张关联的后量子证书，不会凭空产生后量子认证。如果收到了两份签名却只验证一份，另一份仍不是保证。如果两次数学验证都通过，但其中一条认证路径终止于本地不接受的信任锚，关系哈希也不能扩大信任范围。

这也区分了本文与 RFC 9883。RFC 9883 允许既有签名私钥对“主体拥有另一把密钥建立私钥”作出政策可接受的声明，同时明确没有对后者提供技术性持有证明。RFC 9763 则要求 A 的私钥真正签名，并在普通申请流程中由 B 的私钥签署 CSR，之后再记录证书关系。前者的主题是以声明替代某项证明，本文的主题是不要把登记证明升级成未来会话证明。

RFC 9955 讨论混合数字签名方案可能追求的安全与兼容属性。RFC 9763 不选择一个通用组合规则，只把精确关系信号交给其他协议和本地策略使用。

跨 CA 关系背后还有制度安排

若 A 与 B 由同一个 CA 组织处理，机构通常已有检索能力和信任环境。若 B 的申请跨到另一家 CA，新机构可能无法验证原机构的证书。RFC 9763 指出，此时可能需要事先安排，例如合同、预置信任锚，以及对证书申请、签发和接受政策的协议。

同一主体控制两把私钥，并不等于两把私钥受到同等保护。身份核验强度、硬件边界、撤销响应、审计义务和订户合同都可能不同。B 的签发机构应选择与 A 相比较能够提供相当保护的证书政策；“相当”是一个需要留下责任人的判断，不是哈希函数的输出。

所以管理报告中至少要禁止三种偷换：“同一主体”不等于“同一保证等级”；“路径有效”不等于“适合本应用”；“关系匹配”不等于“双重认证成功”。

证书定位本身也是风险面

申请属性包含 Cert A 的位置。同一 CA 组织内，可用 HTTP(S) 指向仅装载证书的 CMS 消息。跨组织时，RFC 推荐用 data: URL 内嵌验证 A 所需的证书和撤销材料；RFC 2397 定义这种 URL。

定位值被签名，不代表目标内容可信。URL 可能指向恶意代码或畸形对象，实现必须验证格式并完整校验证书材料。网络检索还可能被观察，暴露某 CA 正在处理与特定旧证书有关的申请；内嵌数据可以减少这种外部观察，但不会取消解析和验证义务。

审计应保存定位方式、实际取得内容的哈希、解析结果、路径构建输入、撤销材料和信任锚集合。仅凭最终 B 证书，无法还原 CA 当时到底读到了什么。

关联扩展不能抵抗协商降级

混合实现可能遭遇降级：恶意对端不声明对更强算法的支持，使交换只能依赖较弱算法。关系扩展是在证书到达后才被处理的，它不能证明某项能力曾被提出、在途中未被删除，或者最终被选中。

降级证据存在于最低算法配置、受保护的协商记录、实际选定模式和历史行为变化中。证书清单可以回答“准备了多少关联凭据”；只有流量与验证日志能回答“强密钥实际参与了多少会话”。

这正符合 Heng Lu 的运行代码优先：协调文件不能凭出版身份变成运行事实。最小初始规范、本地化未来决定与自愿采用允许共同层严格规定字段、签名、哈希和比较方法，同时把未来接受决定留给实际运行代码的参与者。

现实层分析进一步要求把登记证据、CA 签发断言、证书字节、哈希匹配、会话签名、路径接受、授权决定和服务结果分别记录。它们相互关联，却不是一个绿色标签的不同写法。

一条可以重演的证据链

登记阶段应保留原始 CSR、A 的标识、申请时间、定位信息、被签名字节、签名结论和 A 的路径材料。签发阶段应保留 A 的精确字节与哈希、B 的精确字节、用途比对、政策映射和有效期重叠计算。

运行阶段应保留实际收到的两张证书、各自路径结论、关系哈希计算、实际发生的私钥证明、协商模式、本地政策版本、端点决定和连接结果。目标不是无限日志，而是确保一次失败可以被准确归为登记、检索、信任、证明、协商、政策或应用问题。

来源