Resumo

  • A RFC 6916 coordena a troca de algoritmos entre autoridades certificadoras, pontos de publicação e sistemas que validam o RPKI; não a reduz a uma atualização local de software.
  • A migração de cima para baixo mantém produtos assinados sob os conjuntos antigo e novo durante uma janela de transição e estabelece marcos para os validadores antes de retirar o primeiro.
  • O documento prevê vários anos de trabalho e não especifica uma transição de emergência. Ele orienta mudanças planejadas, mas não resolve uma falha criptográfica repentina.

Trocar a criptografia move uma cadeia

No Resource Public Key Infrastructure (RPKI), declarações assinadas ocupam posições dentro de uma hierarquia. Uma autoridade certificadora (CA) certifica a CA abaixo dela; essa entidade pode emitir certificados e objetos assinados para recursos em níveis inferiores. Um relying party (RP) recupera o material publicado e verifica a cadeia. Operadores de rede podem então usar os resultados da validação em suas próprias políticas de roteamento.

Essas etapas são distintas. A emissão de um certificado não prova que todos os repositórios publicaram os objetos correspondentes. A publicação não prova que todo RP consegue validá-los. E um resultado de validação não determina, por si só, o que um roteador aceitará: a política posterior cabe ao operador. A pergunta da RFC 6916 era, portanto, como mudar o conjunto criptográfico sem interromper um caminho utilizável entre essas etapas.

A RFC 6916, “Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)”, foi publicada em abril de 2013 como Best Current Practice 182 (BCP 182). A lista de autores inclui Roque Gagliano, Stephen Kent e Sean Turner. O texto registra consenso do IETF, não uma ordem pessoal de qualquer um dos autores. RFC 6916

O calendário vem antes do algoritmo substituto

A RFC 6916 não escolhe o próximo algoritmo. Em 2013, determinou que uma transição futura começasse pela atualização do perfil do RPKI definido então pela RFC 6485, seguida por um calendário separado. A RFC 7935 substituiu posteriormente a RFC 6485 e descreve o perfil consultado nas fontes atuais. Por isso, uma transição futura deve atualizar o perfil aplicável, em vez de apenas acrescentar um novo rótulo ao certificado. RFC 7935

O calendário deve indicar cinco datas: quando as CAs precisam estar prontas para emitir com o novo conjunto, quando terão reemitido seus produtos, quando os RPs devem estar preparados, quando o conjunto antigo se torna opcional e quando chega ao fim de vida. A RFC fixa cada marco um minuto depois da meia-noite UTC e pede métricas de preparação para CAs e RPs. O tempo se torna uma condição operacional da confiança: repositórios, validadores e certificados precisam usar a versão correta em cada data.

Também é preciso separar a migração de algoritmos da troca comum de uma chave. A RFC 6489 descreve o rollover de chave de uma CA quando o conjunto de algoritmos permanece igual. A RFC 6916 trata da mudança do próprio conjunto, que afeta certificados, listas de revogação, manifestos e objetos assinados. Um processo capaz de substituir uma chave não resolve necessariamente uma migração criptográfica completa. RFC 6489

Por que a migração começa pela raiz

A sequência é de cima para baixo. Uma CA filha não consegue pedir um certificado no novo conjunto antes que a CA pai possa emiti-lo. O texto também evita certificados de CA cuja assinatura e cuja chave do sujeito pertençam a conjuntos diferentes. Sem essa ordem, seria necessário lidar com certificados mistos e uma estrutura de repositórios mais complexa; a RFC alerta que a migração fora da hierarquia pode provocar crescimento exponencial dos dados publicados.

A hierarquia funciona como parte da superfície de controle. A preparação da CA pai é uma dependência concreta para as filhas; elas não podem ignorá-la. O padrão torna visível a sequência — preparar, emitir, habilitar a validação e retirar o conjunto antigo — sem afirmar que uma autoridade central possa ordenar uma mudança simultânea em todos os sistemas.

A publicação paralela compra tempo

As fases permitem que o conjunto antigo continue servindo à produção enquanto o novo é introduzido e testado. Na fase 0, só o conjunto atual está em uso. A fase 1 começa na data CA Ready: autoridades que não são folhas precisam processar solicitações no novo conjunto, mas os RPs continuam usando o antigo em produção. Os produtos novos podem ser publicados para teste, de preferência em pontos separados.

A fase 2 começa na data CA Go. Cada conjunto de produtos assinados precisa existir nos dois algoritmos. Os RPs podem testar a nova versão e manter a anterior. Para produtos correspondentes — por exemplo, os dados de autorização de origem nos ROAs — a RFC espera resultados equivalentes, consideradas as diferenças de tempo. Se muitas CAs não estiverem prontas, o calendário deve ser republicado. O suporte integral dos RPs ainda não é obrigatório, mas problemas de validação podem adiar a próxima etapa.

Na fase 3, iniciada na data RP Ready, todos os RPs devem conseguir validar o conjunto novo, e a RFC recomenda que deem preferência a seus produtos enquanto as duas versões permanecem disponíveis. A fase 4 começa na data Twilight: o novo conjunto passa a ser obrigatório para RPs e CAs, embora produtos antigos ainda possam existir sem garantia de completude. No fim de vida, o conjunto antigo deve ser depreciado e seus localizadores de âncora de confiança removidos dos pontos de publicação. RFC 6916, seções 4 e 10

A alternativa antiga tem prazo. Um RP que ainda não valida a nova versão pode continuar usando a antiga enquanto ela for obrigatória e estiver disponível. Isso não promete coexistência eterna: é um período limitado para testar, comparar e identificar atrasos antes da retirada do caminho anterior. RFC 6481

O risco alcança os dois lados

A RFC 6916 descreve falhas tanto para quem emite quanto para quem valida. Se uma CA não concluir a migração até o fim de vida do conjunto antigo, seus produtos assinados deixam de ser válidos. Um RP que não migrou perde a capacidade de validar os produtos no conjunto novo. O resultado pode ser uma visão incompleta das informações de roteamento no RPKI.

Isso não significa que todas as rotas desapareçam. O RP produz resultados de validação; roteadores e operadores decidem como tratá-los. Um objeto ausente ou inválido pode influenciar a validação de origem, mas o efeito real sobre o roteamento depende da política local, do software e dos recursos envolvidos. A RFC identifica o risco de uma visão incompleta, não quantifica uma interrupção nem impõe rejeição universal de rotas.

O prazo conservador também revela um limite. O resumo da RFC diz que a transição pode levar vários anos e não especifica procedimento de emergência. Esse ritmo é coerente com uma troca planejada que exige ampla implementação e publicação compatível. Mas fica em aberto outra pergunta: o que ocorre se o algoritmo ou uma chave se tornar inseguro antes do fim do ciclo? A RFC 6916 não fornece esse plano de crise.

O lugar de Gagliano no registro

O perfil público da Cisco apresenta Gagliano como Principal Solutions Engineer e menciona funções anteriores de engenharia e arquitetura na LACNIC, na ANTEL e na Sprint. O percurso reúne experiência de operador, registro regional e fornecedor, mas não comprova por que ele apoiou uma disposição específica. A afirmação segura vem da própria RFC: Gagliano coescreveu um procedimento de consenso que trata a preparação como uma propriedade de toda a cadeia RPKI. Perfil de autor da Cisco

O perfil de algoritmos consultado na RFC 7935 especifica RSA com chave de 2048 bits e SHA-256. Em 2026, um Internet-Draft informativo examina candidatos pós-quânticos e arquiteturas de migração, incluindo publicação paralela e uma árvore mista. Seus autores deixam claro que o texto não atualiza as RFCs 7935 ou 6916, não seleciona um perfil de produção e não autoriza as opções avaliadas para uso operacional no RPKI. A existência de pesquisa não comprova aprovação nem cronograma de uma migração de produção. RFC 7935; draft-yoshikawa-sidrops-pqc-rpki-02

A contribuição duradoura da RFC 6916 é processual. Ela transforma “adotar um algoritmo mais forte” em dependências observáveis: as CAs precisam emitir sob o novo conjunto, os pontos de publicação precisam oferecer os produtos correspondentes, os RPs têm de validá-los e o caminho antigo deve permanecer até que a preparação seja verificada. O documento também mostra o que ainda falta decidir: como medir a preparação, como apoiar quem se atrasa e como separar emergência de migração planejada. Essas decisões cabem aos operadores e aos participantes da padronização.