摘要

  • 路由工作组讨论串的后续回复称，Ben Cartwright-Cox 首先使用 RIPE NCC 新 API 发布了 BGPsec 路由器密钥证书。RIPE 公开仓库中有一张 10 月 22 日签发、对应 AS212232 的证书。
  • RFC 8634 把换钥分成五步：发布替换证书、等待 RPKI 缓存抓取、切换路由器并刷新 UPDATE、按需撤销旧证书、旧证书验证到期后撤回旧密钥。

第一张证书已经离开柜台

BGPsec 不再只是功能公告，而是一份运营者可以检查的文件。10 月 22 日，RIPE NCC 宣布 RPKI API 已支持创建和管理 BGPsec 路由器证书。几个小时后，同一条路由工作组讨论串有人祝贺 Ben Cartwright-Cox 首次用该 API 发布证书。RIPE 公开仓库里确有一张当日签发、对应 AS212232 的 BGPsec 路由器证书。文件不大，下一步却很考验现场操作：在不中断签名路径的情况下更换在线路由器的密钥。

证书写明了用途：扩展用途为 BGPsec Router，密钥用途为数字签名，AS 资源为 212232。签发时间是 10 月 22 日 14:43:46 UTC，到期日为 2027 年 7 月 1 日。证书是这套授权关系的公开一半，供验证方把获授权的 ASN 与公钥对应起来；匹配的私钥留在路由器上。RIPE NCC 的 API 接收 PKCS#10 证书签名请求，并不要求运营者上传那把私钥。

公开 API 文档列出完整的生命周期操作：创建路由器密钥、列出 CA 关联密钥、查询单项、撤销，以及取回证书和签发链。每个 LIR 使用带有 Resource Certification (RPKI) API 权限的 API key。请求包含 ASN、BGP Identifier routerId 和 CSR，CA 再分配路由器密钥 ID。托管边界很清楚：运营者保管签名秘密，CA 签发并发布证书。

因此，首张证书比一条版本公告更有意思。BGPsec 签名随 BGP UPDATE 中的 AS 路径传递。它回答的问题不同于 ROA 或源验证（某个 AS 是否获准起源某个前缀），也不同于 ASPA（记录提供商关系并帮助发现路由泄漏）。路由器证书为 BGPsec 使用授权一把密钥；还需要路由器和对端真正签署并验证路径。

换钥匙要按日历走，别抢秒表

RFC 8634 把换钥分成五个阶段：发布新证书；等待全球 RPKI 缓存抓取；让路由器改用新密钥并刷新外发 BGPsec UPDATE；若要让旧密钥签出的消息失效，可选择撤销旧证书；旧证书的验证期限到期后，依赖方通过 RPKI-Router Protocol 通知路由器撤回旧密钥，路由器再移除旧密钥签过的路由。中间的传播等待，是为了让对端先拿到新公钥，再收到新签名。

API 能把调用交给软件，不能把传播时间压缩掉。靠谱的变更记录应连起替换证书的发布时间、缓存可见时间、路由器切换、UPDATE 刷新，以及任何一次可选撤销。最后的密钥撤回要等旧证书验证到期。脚本若从“创建”直接跳到“撤销”，制造故障倒是很有效率。

RIPE NCC 指出，硬件路由器对 BGPsec 的支持仍落后，渐进部署和性能也有挑战。RFC 8207 说明部分设备可能需要更多内存或更新的处理器；局部部署会形成彼此分隔的签名路径岛屿。密钥切换方案因此必须知道哪些边界路由器能签名、哪些对端会验证、签名链在哪里中断。

公开 API 文档仍把 BGPsec 指向 localcert.ripe.net 的 RPKI pilot；RIPE 仓库中已有 10 月 22 日签发的 AS212232 证书。公开记录目前缺一份带日期的完整轮换轨迹，把证书指纹和发布时间、路由器切换、更新后的签名 UPDATE，以及指定 BGPsec 对端的验证结果串起来；这份轨迹能显示 API 把 BGPsec 推进到真实路由运行的哪一步。

来源：RIPE 路由工作组公告及首次使用回复（2026 年 10 月 22 日）；RIPE 仓库中的路由器证书原件；RIPE NCC BGPsec API 文档；IETF RFC 8209；IETF RFC 8205；IETF RFC 8207；IETF RFC 8634。