摘要

  • Job Snijders、Tom Harrison 与 Ben Maddison 编写的 RFC 9323，让依赖方可以验证：一把获准代表特定 IP 地址或 ASN 子集的密钥，签署了一份包含指定文件精确摘要的清单。
  • 有效 RSC 不会认证自然人、公司职权、文件真伪或交易合法性，也不会要求接收方接受 BYOIP 或互联申请。身份、授权、合同和运营风险仍需各自的证据与决定。

“这就是那份文件”之后

云服务商收到一个 BYOIP 申请。客户希望平台宣告自己已有的地址，随申请提交授权说明与配置材料。服务商最先担心的，往往是文件是否在传输中被替换，以及这批文件能否与相关地址建立可机器核验的联系。

即使两个问题都有肯定答案，工作仍未结束。账户操作者是不是客户本人？他能否代表公司？这份授权是否仍有效？地址是否正在别处使用？即将发生的路由变更是否安全？这些问题不能被一个绿色对勾吞掉。

2022 年 11 月成为 IETF Proposed Standard 的 RFC 9323，恰好为前两个问题提供了克制的工具。Job Snijders、Tom Harrison 与 Ben Maddison 定义了 RPKI Signed Checklist，简称 RSC。它是一种 CMS 签名对象，里面列出互联网号码资源、摘要算法以及一个或多个外部文件的摘要。

文件本身不装进 RSC。接收方对手里的文件重新计算摘要，再与清单比对。验证成功后，可以准确地说：“由这条资源证书路径授权的密钥，签过一份指向这些字节的清单。”不能顺手改写为：“文件内容属实，签署者有公司授权，所以必须执行。”

这条窄边界也解释了 Snijders 的人物位置。IETF Datatracker列出他参与的路由安全工作；OpenBSD把他列为 rpki-client 的主要开发者与可移植版本维护者。贯穿这些工作的不是万能信任，而是让每一项结论都能被复算、失败并说明原因。

清单里到底有什么

RSC 至少要列出一个 IP 地址块或 AS 标识符，同时指定摘要算法和一组 checklist 元素。每个元素都包含消息摘要，也可以带文件名。

清单所列资源必须是内嵌终端实体证书所覆盖资源的子集。密钥因此不能靠多写一行，就把自身权限扩展到无关前缀或 ASN。资源越界时，验证应当失败。

摘要承担另一种职责：锁定精确字节序列。改一个日期、标点、附件或编码，结果通常都会改变。这能揭示替换或篡改，却无法阅读语义。内容错误的文件，也可以拥有完全正确的摘要。

文件名是可选的。采用文件名感知验证时，名称与摘要都必须匹配；不看文件名时，匹配元素本身必须省略名称。这让不同流程能够明确选择：要证明“这份具名文件”，还是只证明“这组字节”。

文件名不能替代摘要。叫做 authorization.pdf 的文件不一定具有授权效力；反过来，文件改名后字节可以完全不变。RSC 的设计迫使系统先说明自己比较的对象，而不是靠一个听起来可信的标签完成推理。

一次性证书不是长期身份牌

每份 RSC 都要新建一对密钥，并使用一次性终端实体证书。对象创建后，私钥应被销毁。证书省略 SIA 扩展，因为这类对象并不进入全球 RPKI 仓库。

这种安排限制了复用与关联。接收方不应把证书当作长期登录凭证、员工胸牌或公司公章。它只服务于一件事：在所选择的 RPKI 信任链下，验证一份特定签名清单与特定资源子集。

RFC 6480早已划出根本边界。资源证书把公钥与 IP 地址或 ASN 关联，但明确不证明证书主体的描述性身份。RSC 没有悄悄补上这一点，也不应被解释成全球企业身份系统。

RFC 9255的警告更直接：RPKI 凭证不得用于认证现实世界的文件或交易。资源管理账户可能由权限很窄的技术管理员掌握。能够管理号码资源，不等于可以签合同、承担债务或代表法人作出商业承诺。

这是实际风险，而不是形式主义。一家公司可能把 ROA 维护交给网络团队或外部供应商，却从未把采购、合规与签约权限一并交出。若系统把“资源账户可控”自动翻译成“公司已同意”，密码学越准确，错误执行反而越快。

验证不是一个总开关

接收方首先验证 RSC 作为 RPKI 签名对象是否成立：CMS 封装、证书路径、资源范围，以及 RFC 9323 对内容的专门规则。随后，它对准备核查的每个文件计算摘要，并查找对应元素。

若流程要求文件名，就同时比较名称与摘要；若不要求名称，匹配元素必须无名称。接收方可以只核查清单中的一部分文件。未用元素并非致命错误，但 RFC 9323 建议给出警告，以便发现漏件或双方流程不一致。

RFC 6488指出，通用签名对象检查是必要条件，却不是充分条件；每种对象还要执行自身的语义验证。RFC 6487规定资源证书配置，RFC 9286则更新验证算法。信封没有破，不代表信里每句话都真。

时间也不能凭空获得权威。CMS 可以带签署时间属性，但通用规则不会因为它有或没有就改变对象有效性。若业务需要有法律或审计意义的提交时间，应使用可信回执或专门的交易日志，而非把可选属性想象成时间戳服务。

成熟系统会保留多个独立状态：签名有效、资源覆盖、摘要匹配、身份通过、公司授权通过、合规通过、运营批准。前几项成功时，后几项仍可等待或拒绝。细分结果不是增加摩擦，而是防止自动化把一项证明升级为全部许可。

为什么它不能进全球仓库

RFC 9323 明确禁止通过全球 RPKI 仓库系统分发 RSC。传输方式留在对象之外，可以是 HTTPS、电子邮件、移动介质，或双方约定的其他渠道。

IANA RPKI 登记表为 Signed Checklist 分配了 OID 1.2.840.113549.1.9.16.1.48 和 .sig 扩展名。这些共同坐标帮助不同软件识别对象，却不会创造一个全球收件箱，也不会赋予对象强制受理权。

不公开分发有现实意义。BYOIP、互联或客户审核材料往往只属于特定双方。若把资源与文件清单之间的联系发布给全世界，可能暴露商业关系或计划，却不会改善路由起源验证。

代价是传输层必须自己负责安全。Web 账户、邮件与移动介质分别面临冒用、泄露与丢失。RSC 能判断收到的字节是否吻合，却不负责加密、不查恶意软件，也不能证明是谁操作了投递账户或所有附件是否齐全。

这种职责拆分仍然是优势。各服务商可以制定自己的认证上传、大小限制、文件类型、保存期限与复核规则，同时共享同一套 RSC 验证语义。标准协调证据，不接管客户关系。

BYOIP 仍然需要运营判断

假设服务商收到一份有效 RSC，所列前缀与文件摘要均通过。它已经获得重要证据：在当前信任锚与证书状态下，一把获准代表该资源子集的密钥签了这批字节。

它还不知道申请者是否属于客户账户、是否有权代表公司、合同是否允许宣告、前缀是否与现网冲突、法规是否允许，以及路由变更会不会造成泄漏或中断。这些问题各有证据来源。

身份应由账户与客户审查证明；公司职权应由授权与法律材料证明；业务目的由合同说明；资源当前状态还需查注册与路由观察；上线安全则要靠过滤、监控、测试与回滚计划。

因此，一份 RSC 可以密码学有效、文件也完全匹配，最终仍被合理拒绝。拒绝不是否认签名，而是另一个条件没有满足。反过来，即使商业关系真实，RSC 失败也不应被人工好感跳过；那说明资源或文件这条证据链有问题。

最强的自动化不是删掉所有判断，而是把可确定部分彻底自动化，并把剩余权限边界写清。语法、证书、资源、签名、摘要与文件名可以机器处理；身份、授权、合规和运营决策也可有规则，但不得复用同一个结论字段。

不把路线图当成部署事实

RFC 与 IANA 登记存在，并不表示生态已经普遍支持 RSC。RIPE NCC 的 RPKI 季度计划把 RSC API 支持列为社区提出、计划在 2026 年第三季度开展的工作；后续用户界面则取决于需求与能力。

这份记录证明实施路径和需求存在，不能证明所有 RIR、验证器、云平台或客户系统已经上线。真正评估要检查实际 API、软件版本、支持算法、错误输出与接收方政策。

测试也不能只走成功路径。证书过期或撤销、资源转移、漏交文件、文件改名、重复摘要、部分核查、未知算法以及资源集合扩张，都要有可解释结果。最重要的组织测试是：RPKI 账户操作者完全真实，但他没有权力批准这笔业务。

MENOG 的公开简介把 Snijders 放在路由与互联实践社群中。RSC 适合这种环境：不同主体共享一项小而精确的证据，再由各自承担风险的人作本地决定。

知道何时停下来的证明

摘要只认识字节，资源证书只认识信任模型下密钥与号码资源的关系。把两者结合，可以得到比纸面声明更强、比现实身份更窄的结论。

这种结论既可携带，也可复现。资源管理者能把证据附在外部文件旁，接收方能独立验证，不必把文件交给全球仓库。双方仍可围绕身份、意图、完整性、时效与风险继续问问题。

Job Snijders 与合作者没有用标准消灭信任，而是确定机器在哪一步有资格下结论。RSC 只签字节，不签真相；正因为它拒绝冒领更多权力，这项证明才更值得进入自动化流程。

来源