摘要

  • RFC 5276 可以为完整路径或不含终端证书的部分路径附上长期 EvidenceRecord；后者降低重复存储，却要求验证者另行证明终端证书与归档文件的签名关系。
  • 路径字节被完整保存，只能证明指定验证材料的存在与完整性；它不能替代响应方身份、信任锚选择、验证政策、后续撤销知识与应用授权。

一批二十年前的签名文件仍然存在。归档系统也保留了从签发机构通往信任锚的证书路径，并能用更新过的长期时间戳证明那条路径未被改动。唯独每份文件所用的终端证书不在路径包里，而是随各自文件保存。

这种设计并不异常。RFC 5276 明确允许它。SCVP 服务器可以为部分证书路径维护 EvidenceRecord，让许多相近年代的文件复用同一段验证基础设施。问题出现在未来团队试图重建结论时：哪一张终端证书属于哪一份文件？它是否和文件一起被长期保护？文件签名是否真的能用该证书中的公钥验证？该证书能否接上那条部分路径？当时又采用了哪一个信任锚和验证政策？

每一份材料都完好，不代表材料之间的关系仍然可证明。RFC 5276 的真正价值，正是在这里把“保存了什么”与“能据此作出什么判断”分开。

完整路径与部分路径不是大小差异

完整路径从终端证书延伸到信任锚。客户端请求路径以及覆盖该路径的 EvidenceRecord，服务器返回 DER 编码的 CertBundle，证据记录直接覆盖这个包。未来验证者可以检查包的哈希与时间戳链，再按指定政策验证路径。

部分路径从签发终端证书的 CA 开始，到信任锚结束。终端证书可以放在归档文件内部，并由文件自身的 EvidenceRecord 保护。这样，多个签名文件无需重复保存同一组中间证书。

存储收益来自拆分，风险也来自拆分。完整路径把终端证书与上游链放在一个被覆盖的返回值中；部分路径则要求未来验证者连接两个保管边界。任何一个环节缺失，都会出现“文件在、证书在、路径也在，但证明组装不起来”的状态。

因此，部分路径的控制清单不能只记一个路径编号。它至少需要文件摘要、签名位置、终端证书摘要、证书与文件的覆盖关系、部分路径摘要、撤销资料的适用区间、SCVP 查询时间、验证政策与信任锚。节省下来的存储空间，不能用丢失关系证据来支付。

EvidenceRecord 必须指向准确的返回值

RFC 5276 扩展 SCVP 的 WantBack 机制。客户端可以请求终端证书、完整路径、部分路径或撤销资料，同时请求与每一种返回信息对应的 EvidenceRecord。

规则非常具体。请求路径证据时，也必须请求路径本身；响应中必须同时出现。完整或部分路径的 EvidenceRecord 覆盖对应 replyWantBack 中 DER 编码的证书包。单一证书的证据覆盖 CertReply 中的证书值。撤销资料可能包含多个 CRL 或 OCSP 响应，每一个都必须能在证据记录中找到覆盖关系；一个 EvidenceRecord 可以覆盖多个撤销项目，但验证者要在最初的归档时间戳中定位项目哈希。

聚合形式 EvidenceRecordWantBacks 用 targetWantBack 标明每条证据覆盖哪一种返回内容，并要求和其他返回项目一一对应。这个设计拒绝一种常见幻觉：只要响应旁边放着一份长期证据，整份响应就自动获得相同证明范围。

真正可以验证的是“这一份证据覆盖这些具体字节”。至于这些字节是否属于正确文件、是否满足当前政策、是否授权某项行为，还要经过后续判断。

空值表达缺证，不表达否定

如果服务器无法提供客户端请求的 EvidenceRecord，RFC 5276 要求保留相应返回类型，但把值置空；在聚合集合里，则为该目标省略 evidenceRecord 字段。如果客户端只要证据却没有请求被覆盖的资料，服务器应报告 WantBack 未满足。

这些状态很容易被自动化系统误读。空值并不表示证书已经撤销，也不表示证书路径验证失败。它只表示所请求的长期保存证据不可用。证书状态和证据可用性是两个轴。

反过来也一样。一份验证成功的 EvidenceRecord 不能把无效路径变成有效路径，也不能把撤销状态改成良好状态。它证明的是被覆盖资料的存在与完整性历史，而不是资料内容的结论必然正确。

控制台应分别展示：请求是否被理解、资料是否返回、证据是否返回、证据是否验证、路径在指定政策下是否通过。把五种状态压成一个“成功”，等于主动抹掉排错线索。

信任锚是输入，不是包内自带的权力

RFC 5280 把信任锚定义为路径验证的输入。不同应用可以使用不同的信任锚；同一条路径可能被一个应用接受，被另一个应用拒绝。基础路径算法给出名称与公钥在某个信任锚下的绑定，不替应用完成所有用途判断。

RFC 5055 让 SCVP 查询显式携带这种政策边界。客户端可以指定验证政策、时间、信任锚、密钥用途、扩展用途与撤销检查。采用服务器默认值可以缩短请求，却会增加未来解释义务：如果没有保存完整政策与参数，后来的人只知道服务器曾说“通过”，不知道它按什么规则通过。

RFC 5276 还要求使用依赖方信任的公钥验证含 ERS 的 SCVP 响应签名。响应里可以携带用于验证 ERS 内层的信任锚，但依赖方可以采用，也可以忽略并使用带外获得的锚。未签名响应中的锚不应被当成可信来源。

这说明签名解决的是响应来源和完整性，不是接受义务。响应自己携带一枚信任锚，并不能迫使接收者相信那枚锚。长期保存也不会扩大它原有的权限。

历史时点会被后来知识改写

SCVP 支持针对过去的 validationTime 处理证书状态。服务器如果没有足够的历史资料，就应返回错误。这个能力让验证者可以判断证书在签署当日的状态，而不是用今天的过期状态粗暴否定旧签名。

但 RFC 5055 明确提醒：历史查询返回的是对那个时点的已知状态，不一定包含后来获得的最完整信息。撤销通知可以在多年后发布，却声明一个早于原查询时点的 invalidityDate。于是，早期肯定响应可以是真实、经过签名且长期保存完好的，同时被后来的证据推翻。

归档系统因此要保存两条时间线。一条是被判断的业务时间：证书在何时被问询。另一条是知识进入档案的时间：路径、CRL、OCSP、撤销通知和政策更新何时被获得。只有第一条时间线，会把“当时所知”伪装成“永远真实”。

请求 nonce 与响应签名也属于这条证据链。如果客户端不核对 nonce，旧响应可能被重放；如果不验证签名或 MAC，响应可能被修改。错误采集不会因保存二十年而变正确。

长期证据需要持续维护

RFC 4998 的 ERS 不是一次封存。归档时间戳可以证明资料在某时存在；在时间戳证书或签名算法失去可接受性之前，要用新的时间戳覆盖旧时间戳。如果哈希树算法变弱，则要启动新链，用新结构覆盖旧时间戳与归档资料。

这是一项维护责任。团队需要监控最后一层时间戳的算法、凭证、续期窗口和验证材料。过了安全窗口再补签，无法凭空弥补中间的证据断层。

ERS 的 cryptoInfos 字段也给出重要警告。它可以保存信任锚、证书、撤销资料或算法适用性说明，但 RFC 4998 指出这些内容本身不受时间戳保护，需要用其他方式验证。容器很有用，不代表容器中的每项内容自动可信。

把档案变成可重建的证明图

一份可审计历史决定，至少要串联十二项收据：归档文件及摘要、文件签名、实际使用的终端证书、SCVP 查询时点、完整验证政策、信任锚集合、响应方身份与签名、返回的路径与撤销项目、每个项目对应的 EvidenceRecord、EvidenceRecord 续期历史、后来替换旧结论的知识，以及应用自己的授权决定。

这张图允许局部失败。路径证据缺失时，可以标注不确定并寻找其他来源，而不是把证书直接判死。政策改变时，可以保留旧结论并计算新结论，而不是篡改历史。后来撤销信息出现时，可以记录“原响应在当时是真实陈述，但不再足以控制现在的决定”。

RFC 5276 没有承诺法律效力，也没有证明某个产品已经正确部署。它提供的是一套精确关系，使验证者不必靠对归档机构的信仰来猜测哪一份证据覆盖哪一份资料。