摘要

  • 有效 RSC 证明的是：具备足够 CA 控制能力的一方，把明确的 AS 号或 IP 资源子集与任意数字对象的精确摘要一起签名。它不证明现实身份、产权、公司代表权、文件真实性或披露完整性。
  • 验收者必须分别保存两套证据：一套说明哪些字节以何种文件名模式命中了哪条清单记录；另一套来自 RPKI 之外，说明现实主体是谁、为何有权为当前事项作出承诺。

设想一场网络资产收购审查。这个场景只是演练，不对应任何真实事件。卖方交来一份地址清单、一份压缩的设备目录和一个 .sig 文件。工具验证成功：两份材料的哈希与 RSC 条目一致，RSC 声明的资源落在内嵌 EE 证书的资源范围内，证书路径与当前 CRL 检查也通过。

清单里其实还有第三条摘要，对应文件并未交付。按照 RFC 9323，这不一定让已经提交的两份文件验证失败；实现应当告警清单条目多于待验证对象。审查团队却把绿色结果写成了三个结论：对方拥有这些资源，对方有权签署转让，材料已经完整披露。

三句话都越过了证据边界。字节吻合，权限没有。

RSC 把什么放进签名

RSC 是一种受 CMS 保护的 RPKI 签名对象。它的 eContent 类型为 id-ct-signedChecklist，OID 是 1.2.840.113549.1.9.16.1.48。IANA RPKI 登记表把它列为 Signed Checklist，并登记 .sig 扩展名；媒体类型为 application/rpki-checklist。

对象内部至少包含一种互联网号码资源：AS 标识、IP 地址块，或两者兼有。资源声明必须是内嵌 EE 证书相应 RFC 3779 资源扩展的子集，而且不得使用 inherit。这不是装饰性元数据。资源超出证书范围、缺少相应扩展或出现继承形式，都应让 RSC 验证失败。

随后是摘要算法与一条或多条清单记录。每条都必须有哈希，可以附带可移植文件名。有文件名的条目必须保持文件名唯一；没有文件名的条目则必须在无名条目之间保持哈希唯一。结构把“资源范围”和“具体字节”连接起来，却没有填入公司名称、自然人身份或交易目的。

绿色状态至少包含四次判定

第一层是通用签名对象验证。RFC 6488要求 DER 编码的 CMS SignedData、规定的签名属性、恰好一张与签名者标识匹配的 EE 证书、可验证的数字签名，以及从 RPKI 信任锚到该证书的有效路径。RFC 6488 明确说这些检查“必要但不充分”，每种对象还要执行自己的规则。

第二层才是 RSC 规则：eContent 结构、资源子集、禁止 inherit、清单唯一性，以及 EE 证书不得含有 SIA 扩展。证书还必须处在有效期内且未被撤销。原本有效的对象会在 EE 证书到期或被吊销后失效。

第三层是文件匹配。验证器对实际收到的字节计算 RSC 指定算法的摘要。若输入带文件名，应使用文件名感知模式：不仅摘要要命中，而且必须恰好有一条命中记录携带完全相同的文件名。若输入没有文件名，则使用文件名不感知模式：必须恰好有一条命中记录省略文件名。

第四层才是组织自己的接受决定。它需要回答现实主体、代表权限、业务目的、必需材料范围和剩余风险。前三层可以自动化，第四层不能被前三层冒领。

一份合格审计记录不应只有“PASS”。它要留下 RSC 字节哈希、OID、EE 证书指纹、链路与信任锚、验证时间、证书有效期、CRL 获取时间和结果、证书资源、RSC 资源、摘要算法、每份输入文件的哈希与文件名、匹配模式、唯一命中项以及全部告警。

精确匹配仍然不等于内容真实

哈希处理的是任意八位字节串，不理解电子表格里的字段、合同里的义务或设备目录中的所有权。修改一个换行符就可能导致失败；两份语义相同但编码不同的文本也可能产生不同摘要。RFC 9323 因此建议把纯文本放入无损压缩封装，减少传输中的意外规范化。

反过来，摘要完全一致也只能证明输入字节与被签字节相同。虚假的资产数量、过期的客户状态或错误的法律陈述，不会因为被准确哈希而变真。密码学可以保护谎言不被篡改，不能把谎言变成事实。

文件名同样只是匹配条件。它能防止“同一摘要但换了指定名称”的某些混淆，却不能证明名称准确描述内容，更不能证明目录之外没有其他文件。

协议允许验证子集，业务却必须定义完整性

RFC 9323 特别说明，一次验证不必使用清单中的所有条目。清单比输入对象集合更长不是协议错误，但实现应当向用户发出警告。这种设计允许不同接收方只验证与自身任务有关的材料，也允许无名数字对象独立使用。

问题在于，工具回答的是“这些对象是否出现在签名清单中”，采购或法务问的却可能是“所有重大事项是否都被披露”。后一个问题需要一份外部的必需材料目录：资源登记权利、客户分配、债务与担保、设备产权、事故记录、访问权限、撤销承诺，以及交易特定的其他条件。

因此验收报告必须区分三种空缺。第一，RSC 条目存在但文件未提交；这是协议层可告警的未使用条目。第二，业务要求某类材料，但 RSC 根本没有相应条目；这只能由外部披露清单发现。第三，文件提交并匹配，但内容缺少关键事实；这需要事实核验和责任声明。

RPKI 的“I”不是身份

RFC 9323 的安全考虑把数据称为自我声明。依赖方不得对签名人作出超出一个事实的假设：对方拥有足够的签发 CA 控制能力，可以创建这个对象。上级 CA 没有替它核验清单数据。

RFC 9255把边界说得更直接：RPKI 中的 I 是 Infrastructure，不是 Identity。资源证书的目的，是为 IP 地址与 AS 号相关声明提供授权结构，不是认证现实世界的持有人，也不是认证商业交易。

托管 RPKI 环境中，资源使用者甚至可能不直接持有签名私钥，而是用账号凭据要求 CA 服务生成对象。能登录的人可能是所有者、权限狭窄的网络管理员、外包供应商，甚至攻击者。即使操作完全诚实，负责号码资源的人也未必能出售资产、代表公司签约或批准机房访问。

RFC 6487还说明，资源证书中的 issuer 与 subject 名称并不用于描述身份。证书链可以准确表达资源授权，同时有意不回答“这个人是谁”。

现实身份必须通过外部权威连接，具体可以是公司登记、资源登记资料、董事会决议、合同授权、法院命令、已知客户认证或其他独立机制。验证问题也不能止于姓名匹配，而应是：这个主体现在是否有权为这项具体决定作出这种承诺？

仓库、吊销与时间都不能补齐空白

RSC 不通过公开 RPKI 仓库分发，而是由当事方在带外渠道传递。没有拿到对象的第三方可能完全不知道它存在。证书序列号缺口或 CRL 上无法对应公开对象的序列号，既不能证明 RSC 存在，也不能证明不存在。

带外分发意味着接收渠道要进入证据链。从对方受控门户、已认证邮件或匿名下载取得同一份字节，密码学结果可以相同，交付人与交易语境却不同。渠道身份不能代替 RSC 验证；RSC 验证也不能代替渠道来源。

EE 证书通常应与单个签名对象一一对应。RFC 6487说明，这样吊销证书就能有效吊销对象。RFC 9323 期望 RSC 使用一次性 EE 证书。CA 在技术上仍可能用同一密钥签多份 RSC，但它们便无法单独吊销。一点便利把本来独立的声明绑进同一个撤销开关。

时间也有限。RFC 9589要求 RPKI 签名对象包含 CMS signing-time，同时禁止 binary-signing-time；但标准不要求该时间值正确，也明确说它不能可靠表示真正签名时刻。它可以被记录，不能被当作可信交易时间戳。

接受记录必须写下“没有证明什么”

稳健的结论应像一份证据保管链，而不是认证徽章：哪些对象在什么模式下匹配，哪些条目没有提供对象，哪些业务必需项根本未列入，证书和 CRL 在何时有效，外部身份如何建立，谁依据哪份授权作出何种决定，以及资源转移、证书吊销、公司授权变化后何时重新审查。

同样重要的是负面范围。文件可以是签名人准确列出的原始字节，同时内容仍然错误；已交文件可以全部匹配，同时重大文件从未列入；现实公司可以控制资源，同时实际操作者没有签约权；权限可以在签名后被撤回。

这些限制不是 RSC 的缺陷。它的价值就在于证明面很薄、规则可复算。错误来自验收者把一个确定的窄答案，扩张成它从未回答的身份、产权和完整性结论。

来源