摘要

  • RIPE NCC 的 RPKI 管理 API 文档说明，LIR 可通过 API 访问密钥管理自身的证书颁发机构和 ROA。
  • 2026 年第三季度的规划把与 RIPE NCC Access 集成的 OpenID Connect 密钥列为“Planned”，并未把它描述为已上线功能。
  • 同一规划称，某个拟议 RPKI 信标的 API 会允许编辑整个 RIPE NCC 地址空间的 ROA，因此未被接受；这不是对当前常规 API 权限的描述。
  • 账户身份、密钥存续状态和某次 ROA 变更的资源授权范围，是三个不同的证据对象，不能用一次登录或一把密钥替代彼此。

一把密钥并不自动说明一次变更的边界

RPKI Management API 的公开文档界定了当前产品表面：LIR 可以通过 API 管理其证书颁发机构和 ROA；文档也列出资源信息、创建 ROA 和设置告警等用途。新建密钥的值只显示一次，保存的是哈希值，不再使用的密钥可以撤销。

这是一套有用的访问控制说明，却不是一条单项变更的授权记录。某把密钥可以关联到一个账户，但这一点本身不能说明：请求涉及哪张资源证书，原本的 ROA 状态是什么，调用者申请了什么操作，或最终是否出现了可观察的状态变化。把“请求已经认证”直接扩展为“资源权限、操作范围和变更结果都已得到证明”，会把不同层次的事实压缩成一个结论。

RIPE-843 进一步说明了这种分离。它写明 API 密钥与特定的 RIPE NCC Access 账户关联；账户被禁用，或用户不再是有关业务应用中的账户维护者时，密钥可以被停用。这是身份和账户生命周期的规则，不是公开的逐请求资源授权台账，也没有必要被表述成那样。

规划中的身份机制与被拒绝的范围机制

在 RPKI 季度规划中，RIPE NCC 表示计划以与 RIPE NCC Access 集成的 OpenID Connect 密钥替换当前 RPKI API 密钥，并计划在 RPKI 仪表板中增加相关管理区块。公开状态是 “Planned”。页面没有给出上线日期、最终令牌设计或日后变更事件的公开格式。

同一页面留下了更具体的设计边界。对于一个拟议的 RPKI 信标，RIPE NCC 说尚未加入它，因为所使用的 API 会允许编辑所有 RIPE NCC 地址空间的 ROA，这一点不可接受。这里的措辞必须限于该被拒绝的信标路径。它并不证明普通 RPKI 管理 API 具有全空间写入能力，也不表示发生过密钥失陷、未经授权的 ROA 或路由事件。

正因如此，OpenID Connect 的计划不能只被理解为“换一种登录”。账户整合或许能改善密钥管理，但它不会自动回答另一道问题：一次会改变状态的请求，在当时被准许触及了哪些资源、哪种操作。

应保存的是小而可核对的范围凭证

答案不是公布密钥、前缀、ASN、原始 API 请求或设备配置。这些信息会扩大暴露面，却未必能说明授权。更合适的是一份边界清楚、对外可核对但不泄露资源明细的范围凭证。

对一项重要 ROA 变更，该凭证可以保存访问政策和实现版本；不含秘密的行为者或客户端类别；账户上下文；受限的已授权资源集合或其受保护摘要；请求操作；受保护的变更前后状态或摘要；授权决定与执行时间；结果；必要时的后续发布观察；以及更正或替代历史。它记录的是决定的形状，而不是持有人的资源清单。

这是一项编辑性设计提议，并非 RIPE NCC 文档中的强制要求。被检查的公开资料也不能证明内部没有其他控制。它们足以表明，计划中的身份方式、账户生命周期和一次具体状态变更的资源范围并不是同一个问题；公开叙述不应把其中一个答案默默当成全部答案。

来源