摘要

  • RFC 5217 设定了一个明确场景：PKI2 同时加入两个 PKI 域，因此 PKI1 可以经由 PKI2 构造到 PKI3 的证书路径；但 PKI1 与 PKI3 并不共同属于域 1，所以按域 1 的策略验证时必须失败。
  • 跨证书与桥接 CA 证明路径可以连接。是否接受还取决于信任锚、策略映射、名称与策略约束、域成员状态、吊销信息，以及依赖方针对具体用途完成的验证。可达性不能替代授权。

被拒绝的完整链条

审计员看到的不是残缺数据。链上的证书一个不少，签名逐级成立，起点正是应用配置的信任锚，终点也是目标订户证书。系统仍然写下“验证失败”。

如果把失败率当作唯一质量指标，这条记录很容易被归入兼容性问题。RFC 5217 却说明，它可能是边界正常工作的证据。

规范中的 PKI2 同时属于域 1 和域 2。PKI1 到 PKI2 有路径，PKI2 到 PKI3 也有路径，因此路径构造器能把两段接起来。但 PKI1 和 PKI3 没有共同的域 1 成员关系。请求按域 1 策略验证时，这条路径不得成功。

证书图回答了“能否连起来”。策略回答的是“谁授权把这条连接用于当前决定”。

构造路径只是发现候选

证书路径构造从某个信任锚出发，寻找一组有序证书抵达终端实体。验证则拿着这组候选，处理策略、名称约束、用途、时间和吊销状态。两步可以由同一套软件连续完成，却不能因此合并成一个事实。

桥接和网状架构扩大了搜索范围，也能减少每两个域之间单独签发跨证书的成本。这些收益只说明远端签发者变得可达，不说明所有应用都应当接受远端证书。

RFC 5217 要求每个 PKI 保留自己的证书策略 OID 和主 CA。它与外部 PKI 建立关系之前，要审阅对方的策略和治理文件，决定可接受的信任程度并做策略映射。跨证书把这个有限关系技术化；它没有把不同制度合并，也没有把所有保证等级视为等价。

双重成员制造了侧门

最值得警惕的不是一条错误链，而是一条过于容易构造的正确链。PKI2 同时连接两个域，算法因此看见了从域 1 进入域 2 的通道。若边界没有写入签名约束，路径发现可能把局部信任扩展成从未被批准的跨域信任。

RFC 5217 把防线放进跨证书：策略映射、策略约束和名称约束应明确排除域外路径。一个域若希望某项限制可靠生效，就不应只寄望所有依赖方恰好配置了同样的本地规则。

成员关系变化也不是通讯录更新。某个 PKI 新增或退出另一个域，会改变可构造的路径集合。它必须通知相关域；相关域必须重新审查跨证书约束。若允许或禁止的路径发生变化，就要吊销旧跨证书并签发写有正确边界的新证书。

签名能固定一份声明，不能让声明所描述的世界停止变化。

有效签名不能替代策略处理

这里最容易出现的误判，是把密码学真实性扩大成业务适用性。跨证书的签名可以证明某个 CA 确实签发了其中的策略映射和约束，也可以防止这些字段在传输中被无痕篡改。但签名不会自动选择依赖方的初始策略集合，不会替应用决定证书适合登录、签约还是代码签名，也不会证明吊销信息在决策时足够新鲜。

RFC 5217 提醒，域若希望限制可靠生效，就要把限制明确放入跨证书，而不是把希望寄托在依赖方的验证策略上。反过来也同样成立：依赖方不能因为跨证书“看起来正式”，就跳过自己的策略输入。签名回答“谁作出了这项声明”；验证回答“这项声明在当前目的下是否足够”。

这也解释了为何拒绝原因必须具体。no path、policy mismatch、name constraint、revocation unavailable 和 untrusted anchor 代表完全不同的控制状态。若它们在运营面板里都变成“证书错误”，组织就无法区分连接故障、权限边界和证据缺失，更无法判断应该修复路径还是保留拒绝。

Bridge CA 不是所有人的根

桥接模式用一个 Bridge CA 管理跨证书，降低多域互操作所需的双边关系数量。RFC 5217 同时划出硬边界：桥接 CA 不得成为任何参与域的信任锚，不应签发普通终端实体证书，并应以中立方式、用自己的域策略 OID 完成映射。

这个设计拒绝把“处在中心”偷换成“拥有最高权力”。依赖方仍从本域选择的信任锚出发。路径经过桥接点时，双方的映射和约束仍要被验证。桥可以降低协调成本，却无权替每个参与者定义风险偏好。

信任列表暴露真正的决策者

本地信任列表由单个依赖方维护，可以直接放入多个信任锚，不必先建立复杂跨认证。代价是每个依赖方都要独立更新。Trust Authority 则为多个依赖方维护共同列表，把管理集中起来。

集中不等于免除判断。把某个 PKI 加入列表之前，依赖方或 Trust Authority 要审查其策略、保证程度、对依赖方提出的义务、所提供的担保，以及吊销或密钥失陷通知；之后还要持续复核。如果不愿继承该 PKI 对其他域成员的信任，必须抑制策略映射。

因此，信任列表不是无害配置文件。加入一个 CA 会使原本被拒绝的证书获得入口；移除一个 CA 可能造成服务拒绝。谁修改、为何修改、影响哪些用途，都必须可追溯。

留下“接受权限回执”

重大依赖不能只保存最终证书链。回执应绑定依赖方与应用、决策时间、验证引擎版本、信任锚指纹及安装来源、目标 PKI 域、用途和初始策略集合。

还应保存准确的候选路径、逐跳处理的策略映射和名称约束、域成员快照、跨证书签发与吊销状态、信任列表或 Trust Authority 版本、CRL 或 OCSP 数据的新鲜度、最终结果、具体拒绝原因，以及应用随后允许或拒绝的动作。

被正确拒绝的链也应保留。它证明系统看见了一条技术通路，却没有让通路越权成为信任。

回执还应能回答一个容易被忽略的问题：同一条链若在不同应用中得到不同结果，差异来自哪一项输入。若答案只能靠临时重演，证据就会随着信任列表、域成员关系或吊销缓存的下一次更新而消失。保存决策快照，才能把当时的授权边界与后来的配置状态分开。

这篇文章没有声称什么

RFC 5217 是信息性备忘录，也承认多域互操作还有其他实现方式。同一条路径在另一信任锚、用途或社群策略下可能成立。这里不指控任何具体 CA、桥接服务或产品存在缺陷。

结论更窄，也更可执行：签名有效、路径存在、属于某个域、被某个应用接受，是四种证据。把它们压成一个绿色状态，才会让接口凭空创造权力。

来源

补充标准记录

  1. RFC 5217 纯文本
  2. RFC 5217 信息页
  3. IETF Datatracker 条目
  4. IETF Datatracker 历史
  5. RFC 4949：互联网安全术语表
  6. RFC 5914：信任锚格式
  7. RFC 5934：信任锚管理要求
  8. RFC 6024：信任锚管理协议要求
  9. RFC 5055：服务器端证书验证协议
  10. RFC 6818：RFC 5280 更新
  11. RFC 6960：在线证书状态协议
  12. RFC 5019：轻量级 OCSP 配置
  13. RFC 6962：证书透明度
  14. RFC 7030：安全传输注册