Resumo

  • A documentação atual da API de gestão RPKI do RIPE NCC descreve como um LIR administra sua autoridade certificadora e suas ROAs com uma chave de acesso à API.
  • O planejamento do terceiro trimestre de 2026 classifica como planejada, e não implantada, a substituição das chaves RPKI atuais por chaves baseadas em OpenID Connect e integradas ao RIPE NCC Access.
  • O mesmo planejamento informa que uma API considerada para uma baliza RPKI permitiria editar ROAs de todo o espaço RIPE NCC; por isso, esse caminho não foi aceito.
  • Vínculo de conta, ciclo de vida de credencial e autorização de uma alteração de ROA limitada a recursos são fatos diferentes e exigem evidências separadas.

Uma credencial não explica, sozinha, uma mudança de estado

A RPKI Management API define a superfície atual de modo útil. Um LIR pode gerir sua autoridade certificadora e suas ROAs pela API. A documentação abrange informações sobre recursos, criação de ROAs e alertas. O valor de uma chave nova é mostrado uma vez, o valor guardado é um hash e chaves sem uso podem ser revogadas.

Essas são propriedades relevantes de acesso e de produto. Elas não constituem um recibo de uma alteração individual. Uma chave pode estar associada a uma conta e ainda assim não revelar qual recurso certificado estava dentro da autorização, qual operação foi solicitada, qual era o estado anterior da ROA ou qual resultado foi devolvido. Autenticação não deve ser usada como atalho para provar, de uma vez, identidade, escopo e transição.

A RIPE-843 reforça a separação. A política estabelece que as chaves de API estão vinculadas a uma conta específica do RIPE NCC Access e podem ser desativadas quando a conta é desativada ou quando a pessoa deixa de ser mantenedora de conta no sistema de negócio pertinente. Trata-se de uma regra para a vida da identidade. Ela não afirma existir um livro público de autorização por solicitação.

O plano de identidade e o caminho de escopo que foi recusado

No RPKI Quarterly Planning, o RIPE NCC diz que planeja substituir as chaves atuais por chaves baseadas em OpenID Connect, integradas ao RIPE NCC Access, e adicionar uma área de gestão no painel RPKI. O estado divulgado é “Planned”. A página não define data de implantação, desenho final do token ou formato público para eventos de mudança.

A mesma página registra um limite mais incisivo. O RIPE NCC não conseguiu adicionar ainda uma baliza RPKI proposta porque a API usada permitiria editar ROAs para todo o espaço RIPE NCC, algo considerado inaceitável. A frase precisa ser mantida em seu contexto: trata-se do caminho de baliza proposto e recusado. Ela não prova que a API comum de gestão RPKI tenha tal alcance, que alguma chave falhou ou que ocorreu uma alteração não autorizada.

Isso torna a passagem para OpenID Connect uma questão mais ampla que login. Melhorar integração de contas e gestão de chaves pode ser útil, mas não responde automaticamente a uma pergunta de controle distinta: quais recursos e qual operação uma solicitação com efeito de estado podia atingir?

Um recibo de escopo pode ser pequeno e suficiente

Não é necessário expor segredos, prefixos, ASNs, chamadas brutas ou configurações. Essa divulgação poderia criar risco operacional sem esclarecer a decisão. Um recibo limitado pode reter o que importa.

Para uma alteração material de ROA, ele poderia registrar a versão da política de acesso e da implementação; uma classe de ator ou cliente sem segredo; o contexto da conta; o conjunto delimitado de recursos autorizados ou um resumo protegido; a ação solicitada; estados anterior e posterior protegidos; tempos de decisão e execução; resultado; uma observação posterior de publicação quando relevante; e a sequência de correção ou substituição. Assim, a forma da autorização permanece verificável sem publicar os recursos de um titular.

É uma proposta editorial, não uma exigência do RIPE NCC. As fontes públicas não dizem que controles internos estejam ausentes. Elas mostram apenas que mecanismo de identidade planejado, estado de uma conta e escopo de uma única mudança são perguntas que não devem receber a mesma resposta por conveniência.

Fontes