Resumo

  • O planejamento trimestral de RPKI atualizado em 17 de setembro de 2026 apresenta primeiro a migração para OpenID Connect e novas chaves de API, depois as frentes de conformidade. O suporte por API a Resource Signed Checklists (RSC) está planejado apenas se houver capacidade, dependendo do avanço das duas primeiras frentes. Uma interface visual pode vir depois, caso exista demanda.
  • Em maio de 2024, a RIPE NCC propôs ao grupo Routing trabalhar com assinaturas RSC na API e no painel após ASPA, ou antes caso a etapa final de padronização de ASPA demorasse. O arquivo de planos registrou RPKI-2024#01 como pedido a investigar. Não há prazo contratual descumprido nesses registros.
  • O RFC 9323 define a lista assinada como vínculo verificável entre hashes de arquivos e um conjunto restrito de recursos numéricos. O objeto não deve ser distribuído pelo repositório global de RPKI. Uma futura API de assinatura não faz, sozinha, a entrega fora desse repositório, a validação independente nem a aceitação do negócio.
  • As fontes consultadas não mostram endpoint público de emissão RSC já disponível, data de estreia, incidente ou titular prejudicado. Reconhecer extensões RSC em uma biblioteca não é lançar um serviço de produção.

A fila muda o significado de “suporte”

Uma linha de um plano pode ser lida como promessa quando o leitor precisa dela para fechar um produto. A linha sobre RSC, porém, foi escrita de outro modo. Ela está no terceiro item do plano de Q4 de 2026: a equipe implementará suporte por API se tiver capacidade, conforme o progresso do trabalho de identidade e de conformidade. O texto ainda condiciona uma interface ao que os usuários venham a pedir. Nada ali fornece data de ativação ou formato definitivo da operação.

As duas frentes anteriores são substantivas. A primeira troca a autenticação interativa do RPKI Dashboard por OpenID Connect, oferecido pelo RIPE NCC Access, e prevê substituir as chaves existentes da API RPKI por chaves integradas ao sistema de acesso. A segunda reúne um projeto de ISO 27001 e outra auditoria SOC 2 Type II iniciada em maio. São controles pertinentes a um serviço que assina declarações sobre recursos. Também ocupam tempo de engenharia. Dizer que a ordem é compreensível não equivale a dizer que o terceiro item já possa ser adquirido ou incluído num compromisso com clientes.

O padrão técnico veio antes. Publicado em 2022, o RFC 9323 permite que uma autoridade certificadora com recursos IP ou ASN delimitados produza uma lista de digests de arquivos assinada. Um destinatário pode conferir se recebeu os mesmos bytes e se a assinatura cabe no conjunto de recursos declarado. Para uma incorporação de endereços próprios numa nuvem, isso pode substituir parte da confiança cega numa carta encaminhada por e-mail. Mas o RFC não entrega à RIPE NCC uma API pronta, nem transforma toda assinatura válida em aprovação de onboarding.

O plano de 2024 não é o contrato de hoje

O relato à Routing WG em 2024 ajuda a reconstruir a expectativa. A RIPE NCC descreveu a assinatura de um desafio enviado por um provedor a quem declara controlar um prefixo. Indicou a intenção de desenvolver assinatura via API e painel após ASPA, admitindo uma antecipação se a última chamada do IETF para ASPA não chegasse. Mais tarde, a entrada arquivada para RPKI-2024#01 ainda prometia estudar os usos e responder.

O documento atual não repete aquela amplitude. Ele fala em API primeiro, condicionada a recursos de equipe; tela, talvez. Essa mudança não prova atraso injustificado. A mensagem de 2024 era uma proposta e a entrada arquivada não dizia “concluído”. Tampouco o plano de setembro diz que um produto lançado foi retirado. O que mudou de forma verificável foi o grau de certeza que um integrador pode atribuir ao projeto. Usar o plano antigo como se ele autorizasse uma implantação presente seria misturar fases distintas.

A documentação de gestão RPKI descreve a administração da CA e de ROAs de um LIR mediante chave de API. Ela não documenta uma operação pública de criação de RSC. Isso não permite afirmar que não há nenhum protótipo interno; apenas impede apresentar a página como prova de uma API aberta. O histórico de rpki-commons registra em 2024 um primeiro passo para reconhecer extensões relacionadas a RSC. Leitura de formato e emissão com responsabilidades operacionais são produtos diferentes.

A assinatura não vai para todos os validadores

Há uma distinção técnica decisiva. A mensagem de 2024 começa usando uma descrição ampla que sugere publicação de checklists no RPKI, mas logo esclarece que RSCs não são depositadas no repositório global: circulam entre quem assina e quem verifica. O RFC 9323 explicita a regra. O certificado de uso único não inclui a extensão que apontaria para o local do objeto no repositório, justamente porque essa não é a forma de distribuição.

Uma ROA publicada pode ser consumida por validadores de origem de rota. A RSC tem outro percurso. O solicitante precisa obter o arquivo assinado, enviá-lo ao destinatário junto dos arquivos cujos hashes aparecem na lista, e o destinatário precisa checar certificado, recursos, digest e bytes recebidos. Só depois aplica suas regras sobre identidade do cliente, escopo do contrato e mudança a realizar. O retorno “sucesso” de uma API resolveria a primeira parte; não faria uma autorização de roteamento aparecer na Internet nem obrigaria o provedor a aceitar o cliente.

Se a RIPE NCC começar pela API, desenvolvedores vão precisar de um contrato claro para identidade do chamador, limites de recurso, entrega do .sig, erros, ciclo de vida e exemplos verificáveis por ferramentas independentes. O plano atual ainda não informa esses detalhes. Listá-los como critérios de aceitação não significa atribuir uma falha de segurança a um serviço que as fontes sequer mostram em operação.

O controle da CA não é título de propriedade

O RFC 9323 é explícito sobre o alcance da prova. Os dados da RSC são declarações do próprio assinante; a validação mostra controle suficiente sobre a CA emissora para produzir aquele objeto, não identidade societária, autoridade contratual, verdade dos arquivos ou propriedade jurídica de um ASN. A antiga entrada de planejamento da RIPE NCC cita “prova de propriedade de um ASN” como exemplo de interesse, mas essa expressão não pode ampliar o significado da assinatura definido pelo padrão.

Outros artigos da BTW já examinaram essa fronteira criptográfica. Aqui o objeto editorial é o serviço específico da RIPE NCC: o que está de fato previsto, quais dependências podem adiar sua exposição, como um arquivo destinado à contraparte sairia da API e em qual ponto outra instituição assume a decisão. Até que haja especificação e implantação públicas, o registro correto é restrito: dois trabalhos em curso, API RSC condicional, tela eventual. Não há usuário afetado ou episódio de falha a atribuir.

Fontes