摘要

  • RIPE NCC 于 2026 年 9 月 17 日更新的 RPKI 季度计划把 OpenID Connect 与 API 密钥调整列为第一项，合规审计列为第二项；资源签名清单（RSC）的 API 支持排第三，取决于前两项工作的进展与剩余人力。用户界面还要另看需求。
  • 2024 年 5 月给 Routing 工作组的更新曾设想在 ASPA 之后推进 RSC 的 API 与仪表板，若 ASPA 的标准程序延后，也可能提前。随后归档计划将 RPKI-2024#01 记为待研究的社区请求。这些是规划脉络，不是逾期交付的证据。
  • RFC 9323规定，RSC 用受到资源范围约束的签名关联文件哈希，而且不得通过全球 RPKI 仓库分发。即使将来有签发 API，签名文件的交付、对方验证与业务接受仍是三件独立的事。
  • 已核对的公开材料不能证明 RIPE NCC 现有面向公众的 RSC 签发接口、确定上线日期、实际故障或受损用户。代码库能识别相关扩展，也不等于生产服务已经开放。

排在第三的到底是什么

季度计划是工作安排，不是产品说明书。当前页面先写 RPKI 仪表板改用 RIPE NCC Access 提供的 OpenID Connect，同时把现有 RPKI API 密钥替换为与单点登录整合的密钥。第二项涉及全机构 ISO 27001 工作及五月启动的新一轮 SOC 2 Type II 审计。第三项才是社区请求的 RSC：若前两项的进度让团队有余力，就实施 API 支持；界面将来是否加入，再由需求决定。

这种次序有充分理由。新的签署能力必须知道请求由谁发起，能够触及哪些资源，签署系统如何接受审查。问题不在于 RIPE NCC 为什么先做这些基础工作，而在于外部使用者如何理解“计划”。接口说明、权限规则、可下载的签名对象、测试向量和错误处理都还没有在这个 RSC 项目中公布。把第三项采购成一个已经可调用的端点，会把尚未解决的工程风险悄悄转嫁给客户。

RSC 的标准本身并不欠缺。RFC 9323于 2022 年公布，允许在特定 IP 地址或 ASN 范围下签署一份包含若干文件摘要的清单。接收方可核验签名与文件字节是否对应。这对“自带 IP”入驻云平台、网络互联资料核验等场景有用，但标准定义对象，不负责让某一家注册机构交付产品。已经标准化、列入研发清单、生产可用，是三个不同的状态。

2024 年的设想不能替 2026 年签约

RIPE NCC 在 2024 年的 Routing 工作组邮件里，用运营者签署服务提供方发来的挑战文件举例；这正是可能减少普通授权信函伪造或转发争议的场景。邮件还提出，ASPA 之后可做 RSC 的 API 与仪表板；如果 ASPA 的 IETF 最后征询没有推进，RSC 也许能提前。归档的季度计划则仅记录“知道存在多种用例，将研究并正式回应”。

到了今年 9 月，公开顺序变了：身份与审计先行，RSC 只先考虑 API，界面甚至不一定做。这不自动构成失约。2024 年的邮件没有确定交付日，归档条目没有宣告服务上线，当前计划也没有承认曾撤回产品。它确实改变了使用者可据以行动的边界：任何自动化系统都应按现行计划评估风险，而不是继续依赖两年前较宽的设想。

现行 RPKI Management API 文档介绍 LIR 使用访问密钥管理证书颁发机构和 ROA，没有给出公共 RSC 创建接口的调用契约。不能由此推断 RIPE NCC 内部绝无测试环境；只能说外部开发者不能把该文档当作 RSC 上线证明。rpki-commons 的版本记录说 2024 年起开始识别 RSC 相关扩展。识别一个格式，与向会员签发对象、提供下载和维护运维承诺相距很远。

这份签名不进入全球仓库

RSC 与 ROA 最容易混淆的地方，是两者都借用 RPKI 的证书链。2024 年邮件开头有一处宽泛表述，听起来像要把签名清单发布到 RPKI；后文却明确解释，RSC 不进入全球 RPKI 仓库，而是在签署方与验证方之间交换。RFC 9323 的规定更清楚：这种一次性终端实体证书不包含用于定位仓库对象的扩展，清单不得通过全球仓库分发。

因此，未来即便 RIPE NCC 的 API 返回“签署成功”，交易也尚未完成。请求方要取得 .sig 文件，并把它与原始文件交给特定接收方；接收方核对证书路径、资源集合、摘要算法与实际文件；随后再判断这些材料能否满足自己的入网、合同或核验程序。全球路由验证系统不会因为 RSC 被创建就自动获得它，RSC 也不会因此成为一份允许某个 AS 发布路由的 ROA。

这个分工既是产品问题，也是责任边界。API 优先可以让熟悉自动化的运营者先行使用，未必需要图形界面。但若没有稳定的取件方法、明确的资源权限、独立验证范例和失败后的纠正路径，外部系统仍难以安全依赖它。这里列出的不是已发现的漏洞，而是将来判断“服务可用”的具体条件；公开计划尚未回答这些问题。

正确的字节，不等于交易授权

RFC 9323 还提醒接收方，清单中的数据由签署者自行陈述；有效签名只能证明签署者对发证 CA 有足够控制，不能直接推出企业身份、法律所有权或某份文件的真实性。RIPE NCC 较早的归档条目用“ASN 所有权证明”举例，不能据此把技术签名写成产权证书。BTW 已有文章详细讨论哈希正确与法律授权的区别，本篇不重复那个一般论证。

这里要追问的是 RIPE NCC 将来到底提供哪一段能力，又有哪些决定必须留给运营者和交易对方。现在能核实的是：前两项工作在进行，RSC API 仍有条件，界面只是一种后续可能，标准要求不经全球 RPKI 仓库分发对象。不能凭此预告上线，更不能虚构故障。真正的发布检验应从一次可复现的签发、取件与独立验证开始，而不是从路线图上的“支持”二字开始。

来源