摘要

  • RFC 3029 允许验证服务正确执行并签发 Data Validation Certificate，而证书中的验证结果可以是无效；执行、响应来源与对象状态是三件事。
  • DVC 将请求或摘要、时间、序列号、策略、总体状态与逐项结果保留下来，依赖方仍须验证响应，并决定该结论是否足以支持自己的行动。

“证书”这个词容易让界面设计走向一枚绿色印章，仿佛签名天然等于批准。RFC 3029 的 Data Validation Certificate（DVC）不是批准层，而是一份经过签名的判断记录。它的价值恰恰包括诚实地保存否定结论。

规范对这一点没有含糊：DVCSCertInfo 是数据验证服务成功执行后返回的结构，但“执行成功”不一定意味着“验证成功”；其中可以包含有效或无效结果。请求能够被解析和处理，服务器能够正确签名，待验证文档仍然可以不符合规则。若把三种状态压成“操作成功”，协议真正提供的信息就消失了。

四类服务限定了四种事实

cpd 证明请求者在所示时间持有并向服务器提交了实际数据。ccpd 只接收消息摘要，证明的是对该摘要的持有主张；服务器并未因此见到原始字节。把两者都写成“数据已提交”，会把标识符的证据膨胀成对象的证据。

vsd 验证数字签名文档，不仅检查数学签名，还要结合证书路径、状态信息与信任策略。vpkc 在指定时间验证一个或多个公钥证书及其路径和撤销状态。DVCS 可以利用 CRL、OCSP、目录或其他 DVCS，但 RFC 3029 明确说它不是大型开放环境中 CRL 和 OCSP 的替代品。

四种服务产生外形相近的 DVC，却回答不同问题：数据是否送达、摘要是否送达、签名文档是否满足策略、证书在某时刻是否满足路径与状态规则。一个统一的“已验证”标签无法忠实表达它们。

签名包住的是结构化判断

DVC 是 CMS SignedData。内部的请求信息说明服务与上下文，messageImprint 把结果绑定到提交材料，单调递增的序列号区分证书，响应时间记录判断时点，策略字段说明规则，总体状态概括结论，详细结构则保存每张证书或每个签名的结果。若时间来自外部时间戳或另一份 DVC，服务器还必须先验证该外部值。

因此，客户端不能只验证最外层签名。RFC 3029 要求检查可接受的时间、DVCS 名称、请求信息、摘要、签名、状态、服务与策略，并另行判断 DVCS 签名证书是否有效。签名正确但绑定到错误摘要的响应，回答的是另一项请求；在不可接受策略下得到的正确结果，也不够支持当前依赖方。

策略字段说明为什么同一对象可能得到不同但诚实的结论。服务器可以选择不同信任根、撤销信息或签名数量门槛。DVC 的准确含义不是“对象普遍有效”，而是“服务器 Y 在时间 T、依据策略 P，对摘要 Q 返回结果 R”。

总体状态不能吞掉逐项结果

在证书集合中，总体失败可能只来自一个元素，依赖方需要查看逐项结构。在多重签名文档中，一个签名失败也未必导致整体失败；若策略只要求足够数量的签名，服务器可以返回 grantedWithMods。反过来，若策略要求更多签名，即使现有签名都在数学上正确，整体仍可能失败。granted 只用于全部签名验证成功的情形。

总体状态是一项策略结论，不是细节的替代品。WAITING 也不是较弱的成功，它表示最终响应尚未就绪，后续处理由服务策略规定。

负面结论与无法可信响应不同

服务若已执行，签名 DVC 可以可信地报告“对象无效”。请求若因格式或请求者认证问题根本无法执行，服务器返回的是错误通知。前者回答了验证问题，只是答案为否；后者没有进入实体判断。

若 DVCS 自己不能产生有效签名，例如已知签名密钥泄露，RFC 3029 允许发送没有签名者信息的错误结构，但客户端必须把它当作关键且致命的错误，不得默认信任内容。签名的否定判断是可归属的负面证据；未签名错误是响应权威本身失效。

RFC 3029 于 2001 年 2 月以 Experimental 身份发布，并非 Internet Standard。后来的 RFC 3379 与 RFC 5055 分别处理委托路径验证需求和 SCVP。它们不能证明 DVCS 获得实际部署。历史意义在于另一点：把验证计算交给中心服务，并没有把最终判断也交出去；问题、策略、结论与应用决定仍须分别保存。

来源

Lu Heng 并未撰写或认可 RFC 3029 及相关 PKIX 标准；本文仅把其文章作为明确披露的分析视角。