摘要

  • RFC 9323 定义了一份由资源持有者签名的数字对象校验清单，可证明这份清单由相应资源控制者生成。
  • RIPE NCC 2024 年计划提供 API，年度报告把工作列为暂停；2026 年第四季度仍标注为有条件的计划事项。

RSC 的标准已经写好快四年，RIPE NCC 的 API 还在等日历给它腾位置。

RPKI Signed Checklist（RSC）把一组数字对象的校验值列在清单里，再用指定的互联网号码资源签名。验证签名，可以确认清单由这些资源的持有者制作。RFC 9323 举出的用途包括 BYOIP 接入时核验资源，以及网络之间建立物理互联时确认相关材料。

RSC 回答的是一个具体问题：这份校验清单是否由指定互联网号码资源的持有者生成？对于 BYOIP 接入或网络物理互联，接收方得到了一份可验证、可带入自身业务核验流程的证据。

RFC 也没有规定 RSC 必须走哪条传输通道。它不会被放进全球 RPKI 仓库，传输方式留给实现者。文件可以通过网页、签名邮件或其他方式交接。API 能让创建和管理少些手工活，但 API 是一种服务入口，不是标准本身，更不是唯一可能的入口。

RIPE NCC 的计划记录把时间线摆得很直白。2024 年活动计划建议先通过 API 实现 RSC 与 BGPSec，再接入 RPKI 仪表盘。2024 年年度报告将这项承诺标成“暂停”，并把 RSC、BGPSec 和 ASPA 列在 2025 年计划中。

到 2026 年第四季度的 RPKI 计划，RSC API 仍是“计划中”。条目明确说要看团队产能，还依赖另外两项工作的进度：API 密钥与 OpenID Connect，以及合规工作，其中包括全组织 ISO 27001 审核和新一轮 SOC 2 Type II 审计。界面可能等到有需求再做。计划没有给出交付季度，也没有把延迟归因于某一项工作。

落差发生在规范完成与服务可供运营人员使用之间。公开材料没有统计其他工具或渠道上已有多少 RSC，因此不能把这段路线图读成部署数量；它能说明的是，RFC 和托管服务的时钟并不同步。

正在筹备 BYOIP 或网络互联的团队，可以先把证据收集和验证步骤摆在流程里，别把一项“计划中”的 API 当成已经可用。将来 API 也许能缩短交接，但签名覆盖什么、交易对手是谁，仍要分别核验。

RFC 已经落纸。剩下的是排期、界面，还有能把它做出来的团队工时。

来源