Resumo

  • A migração pós-quântica do RPKI é justificada como preparação contra riscos, mas não existe uma data confiável para um computador quântico criptograficamente relevante. A resposta correta é uma preparação em etapas com evidências, não uma transferência apressada de autoridade para a AC ou provedor que se mover primeiro.
  • Os padrões do IETF devem definir certificados interoperáveis, entidades assinadas, comportamento do validador e marcos de transição. As ACs devem implementar essas obrigações. Nenhum desses papéis confere a uma AC a propriedade dos recursos representados, da chave privada do titular ou o direito de impedir a mudança para outro serviço qualificado.
  • A RFC 6916 já trata a migração algorítmica como uma transição de vários anos de cima para baixo, com conjuntos de produtos paralelos e datas de preparação definidas. Sua estrutura é útil, mas uma transição quântica também requer regras explícitas contra aprisionamento, equivalência semântica, downgrade, emergência e reversão.
  • Os padrões ML-DSA e SLH-DSA do NIST fornecem pontos de partida criptográficos maduros, mas não uma seleção automática para o RPKI. Uma proposta individual de junho de 2026 do IETF define o perfil ML-DSA-65 para experimentos, enquanto registra honestamente evidências incompletas de entidades assinadas e validação multi-validador.
  • A publicação paralela de RSA e pós-quântico deve ser julgada pela semântica de roteamento resultante, não pela identidade byte a byte. Divergências em autorizações de rota, estado de revogação ou manifestos devem ser visíveis e nunca mescladas silenciosamente em uma resposta improvisada.
  • A custódia de chaves controlada ou autorizada pelo titular deve permanecer portátil entre provedores de hardware e serviço. Chaves não exportáveis podem ser substituídas por meio de renovação coordenada; elas não devem se tornar uma desculpa para uma AC prender o relacionamento de certificação.
  • A reversibilidade requer hierarquias de teste isoladas, pilotos de produção medidos, fallback limitado, retirada limpa de chaves e um caminho de retorno definido para o caso de falha da nova suíte. Um fallback clássico permanente se tornaria um canal de downgrade em vez de uma função de segurança.
  • O NRS deve publicar uma carta de defesa da migração para 2025-2035 cobrindo direitos de decisão, limites de evidência, neutralidade do provedor, suporte a pequenos operadores, resposta a incidentes, métricas públicas e revisão independente antes de qualquer data de produção obrigatória.

O risco quântico é real, mas o cronograma permanece incerto

A preocupação de segurança é direta. A computação quântica em larga escala poderia tornar vulneráveis algoritmos baseados em fatoração de inteiros ou logaritmos discretos de uma forma que a computação clássica comum não faz. O perfil de produção atual do RPKI usa assinaturas RSA PKCS #1 v1.5 com SHA-256 e chaves RSA de pelo menos 2048 bits. Um computador quântico criptograficamente relevante minaria a suposição de que apenas o detentor da chave privada pode criar uma assinatura RSA válida.

Esta afirmação não fornece uma data de implantação. O progresso em hardware quântico, correção de erros, estimativas de recursos e viabilidade técnica permanece incerto. A governança de registro deve resistir a dois erros simétricos: declarar a ameaça imaginária até que ocorra uma ruptura pública, ou tratar cada previsão como motivo para substituição imediata. As infraestruturas críticas não podem iniciar uma migração global no dia em que uma suíte antiga falha, mas também não devem forçar uma suíte imatura para produção apenas para parecer preparada.

A urgência difere de dados criptografados de longa duração. Um invasor pode coletar dados criptografados hoje e descriptografá-los depois se o texto simples permanecer valioso. As assinaturas RPKI autorizam principalmente um estado atual ou limitado no tempo, e as partes confiáveis buscam repositórios em mudança. Isso reduz alguma exposição de 'colheita agora', mas não elimina o problema de transição. Uma capacidade futura de forjar certificados ou entidades assinadas poderia criar autoridade de roteamento falsa, e uma migração de emergência apressada seria especialmente perigosa em um sistema hierárquico.

A preparação deve, portanto, começar com um inventário criptográfico, experimentos de implementação, suporte de hardware, medições de repositório, interoperabilidade do validador e regras de governança. Não deve começar com um mandato do provedor. A questão-chave para 2025 a 2035 é se o sistema pode evoluir deliberadamente antes que o RSA não seja mais seguro, enquanto retém flexibilidade suficiente para corrigir um algoritmo, implementação ou cronograma errados.

Os padrões do NIST de agosto de 2024 mudaram materialmente o ponto de partida. A FIPS 204 define ML-DSA, um padrão de assinatura digital baseado em rede. A FIPS 205 define SLH-DSA, uma alternativa sem estado baseada em hash. A FIPS 203 cobre um mecanismo de encapsulamento de chave em vez de assinaturas, portanto é menos diretamente relevante para assinar objetos RPKI. O planejamento de transição do NIST indica a depreciação e retirada de padrões vulneráveis à computação quântica até 2035 em seu próprio contexto de padrões, com sistemas de maior risco devendo migrar mais cedo.

Esses desenvolvimentos justificam o trabalho agora. Eles não decidem a suíte RPKI. O RPKI tem restrições específicas de certificado, CMS, repositório, manifesto, revogação e parte confiável. Um algoritmo padronizado e teoricamente seguro pode ainda impor tamanho de entidade, custo de assinatura, hardware, interoperabilidade ou comportamento operacional inaceitáveis nesse ambiente. A seleção técnica requer evidências RPKI; a seleção institucional requer autoridade legítima e verificável.

As chaves RPKI representam autorização limitada, não propriedade

A arquitetura descrita na RFC 6480 segue a hierarquia existente de alocação de recursos numéricos. Certificados de recurso vinculam uma chave pública a endereços IP ou números AS incluídos nas extensões do certificado. O certificado permite asserções criptograficamente verificáveis no RPKI. Ele não transforma a chave privada em um título de propriedade, nem faz da AC emissora a proprietária dos recursos representados.

Esta distinção é importante durante a migração porque cada titular pode precisar de novas chaves, certificados e produtos assinados. Uma AC pai deve estar pronta para emitir sob a nova suíte antes que seus filhos possam migrar no modelo estabelecido de cima para baixo. Essa dependência técnica dá ao pai poder de sequenciamento. Não justifica uma alegação discricionária de que um filho deve entregar a custódia, aceitar um serviço afiliado ou renegociar seus direitos de recurso subjacentes.

A autoridade reconhecida do titular deve permanecer o invariante entre as suítes criptográficas. Certificados correspondentes podem usar chaves e codificações diferentes enquanto representam o mesmo conjunto de recursos. Autorizações de rota correspondentes podem ter o mesmo significado de roteamento enquanto as assinaturas diferem. A migração é uma mudança em como a autoridade é verificada, não uma transferência da autoridade em si.

A política da AC deve afirmar isso claramente. Emitir um certificado substituto não cria uma nova alocação, apaga uma disputa existente, cura uma autoridade subjacente defeituosa ou permite que um provedor reivindique controle benéfico. Por outro lado, a posse de uma chave privada pós-quântica não pode substituir uma transferência legal de recurso ou revogação reconhecida pelas regras de governança. O controle criptográfico e o reconhecimento do recurso devem permanecer conectados sem serem confundidos.

A mesma regra se aplica à operação hospedada. Uma AC ou serviço contratado pode gerar e manter chaves para um cliente que escolhe a assinatura gerenciada. Ela executa uma função técnica limitada para o titular reconhecido. Uma migração que requer novo hardware ou chaves maiores não deve ser usada para reescrever esse relacionamento como custódia permanente. O cliente deve reter visibilidade, aprovação, registros, um caminho para atualizar para operação delegada e uma saída documentada.

O NRS pode tornar o invariante aplicável através de uma carta de direitos de certificado. A carta deve proteger a geração de chave autorizada pelo titular, escolha do provedor, serviço parental oportuno, acesso à publicação, exportação de evidências, renovação de rotina e emergência, monitoramento independente e revisão de ações adversas. Esses direitos se aplicam à suíte atual e às suítes de substituição. Nenhuma exceção de migração deve permitir recentralização silenciosa.

A autoridade de decisão deve ser dividida por função

Nenhuma instituição única deve decidir todos os aspectos da migração quântica. O IETF é o fórum apropriado para especificações técnicas interoperáveis da Internet: identificadores de algoritmo, perfis de certificado e entidade assinada, comportamento da parte confiável, gerenciamento de repositório e procedimentos de transição. Sua revisão aberta pode expor conflitos de engenharia e produzir requisitos comuns. Ele não aloca recursos numéricos nem opera cada AC.

As ACs RPKI implementam os padrões técnicos como parte de suas responsabilidades de certificação. Elas geram ou aceitam solicitações de certificado, emitem certificados, gerenciam revogação, publicam produtos assinados e apoiam transições de filhos. Os operadores de âncora de confiança têm um papel particularmente importante porque sua prontidão afeta a hierarquia abaixo. Sua autoridade operacional deve ser limitada por marcos publicados, evidências de conformidade e observação independente.

As partes confiáveis decidem quais âncoras de confiança e políticas algorítmicas aceitam. Esta não é uma nota de rodapé teórica. Uma nova suíte só tem efeito prático quando os validadores podem buscar e verificar, produzir a saída validada esperada e entregar essa saída aos sistemas de rede. Os operadores precisam de configurações claras para apenas antigo, aceitação paralela, novo preferido com fallback limitado e apenas novo. Padrões ocultos transformariam política local em comportamento global acidental.

Os titulares de recursos decidem como suas chaves são mantidas no perfil aceito, quem pode operá-las, quais autorizações de rota pretendem e qual provedor qualificado os auxilia. Eles não escolhem individualmente um algoritmo global arbitrário e esperam aceitação universal. Sua autonomia é exercida dentro de regras interoperáveis, com escolhas significativas sobre custódia, suporte e tempo durante janelas permitidas.

A governança do NRS deve conectar essas funções sem absorvê-las. Pode representar as necessidades dos membros em discussões de padrões, qualificar serviços interoperáveis, coordenar exercícios de prontidão, publicar evidências, proteger portabilidade e fornecer revisão independente. Não deve anunciar uma suíte proprietária, forçar os membros a usar uma chave detida pelo NRS ou reivindicar que uma migração técnica estende o título da Sociedade sobre recursos.

Governos e autoridades de segurança podem publicar datas de transição para sistemas sob sua jurisdição. Essas datas podem influenciar fornecedores e entidades, especialmente redes do setor público. Elas não devem fragmentar o RPKI global em raízes nacionais incompatíveis. O NRS e os RIRs devem mapear obrigações aplicáveis, buscar implementação interoperável e divulgar conflitos antecipadamente. A segurança global do roteamento depende da validação compartilhada, mesmo quando as leis de aquisição diferem.

A RFC 6916 fornece uma estrutura, não uma resposta constitucional completa

A RFC 6916 antecipou que o RPKI eventualmente precisaria de uma suíte algorítmica mais forte. Ela descreve uma transição planejada abrangendo vários anos, em vez de uma troca de emergência. O modelo é de cima para baixo: as autoridades pai se tornam capazes antes dos filhos. Ele define marcos para prontidão da AC, produção da AC, prontidão da parte confiável, um período crepuscular e eventual fim de vida para a suíte antiga.

O design usa conjuntos de produtos paralelos correspondentes. Durante as fases principais, certificados, listas de revogação, manifestos e entidades assinadas podem existir em ambas as suítes. As partes confiáveis podem testar a próxima suíte enquanto continuam a usar a suíte atual, depois preferir a nova suíte enquanto retêm o caminho antigo por um intervalo limitado. Este é um mecanismo de segurança importante porque uma PKI global não pode depender de todas as implementações mudarem ao mesmo tempo.

A estrutura também expõe poder de governança. Alguém deve publicar o cronograma de transição, decidir os limites de prontidão e determinar quando a suíte antiga atinge o crepúsculo e o fim da vida. Um pai pode atrasar um filho ao não suportar a nova suíte. Um validador pode continuar a aceitar a suíte antiga após o limite de segurança pretendido. Um provedor pode usar a complexidade da transição para desencorajar a saída. A sequência técnica precisa de regras institucionais em torno dessas ações.

A RFC 6916 não define explicitamente a transição de emergência. Esta omissão é compreensível para seu modelo planejado, mas a preparação quântica não pode ignorar a possibilidade de evidências aceleradas: um avanço criptanalítico, um desastre de implementação ou uma indicação confiável de que a segurança do RSA se deteriorou mais rápido do que o esperado. O NRS e os RIRs precisam de uma estrutura de decisão de emergência que não improvise propriedade, âncoras de confiança ou fallback sob pressão.

O procedimento existente também antecede os tamanhos atuais de entidades pós-quânticas e as realidades de implementação. A publicação paralela pode multiplicar os custos de transferência, cache e validação do repositório. O sistema precisa de medições em ACs grandes e pequenas, diversas condições de rede e múltiplas implementações de validador. Um cronograma que apenas os operadores com mais recursos podem cumprir transformaria a segurança criptográfica em uma nova barreira à participação.

O suplemento constitucional deve definir cinco coisas: quem pode propor e aprovar marcos; que evidências interoperáveis são necessárias; como os titulares recebem acesso igual à migração; como a divergência e o downgrade são tratados; e como as decisões podem ser revertidas. Os padrões descrevem o comportamento válido. A governança determina se o poder de exigir esse comportamento é exercido de forma justa.

A proposta de 2026 para o RPKI é evidência de progresso e incompletude

Um rascunho individual da Internet submetido à comunidade SIDROPS do IETF em junho de 2026 fornece um marcador atual útil. Ele propõe ML-DSA-65 como o principal candidato para a próxima suíte de assinatura RPKI e reutiliza convenções de certificado pós-quântico e CMS desenvolvidas em outros lugares do IETF. Ele visa manter a arquitetura RPKI existente, o modelo de repositório e o modelo de saída validada orientada a roteador intactos.

A proposta não é um padrão da Internet adotado e não deve ser descrita como tal. Seu status é importante porque as decisões de migração podem se tornar politicamente sensíveis uma vez que as instituições invistam. Tratar uma proposta inicial como certa favoreceria os primeiros implementadores e fornecedores antes que evidências independentes existam. A resposta apropriada é testar a proposta rigorosamente e comparar alternativas com base em critérios publicados.

Sua honestidade é valiosa. A revisão inicial relatou a geração de certificados de AC ML-DSA e SLH-DSA, certificados de entidade final e listas de revogação usando uma biblioteca criptográfica contemporânea. Também relatou que o caminho CMS de linha de comando testado não produziu os dados assinados ML-DSA necessários, portanto manifestos RPKI completos e autorizações de rota não foram gerados naquele ambiente. A interoperabilidade multi-validador com objetos RPKI pós-quânticos completos permaneceu como trabalho futuro.

Isso não é evidência de que ML-DSA não pode funcionar no RPKI. É evidência de que uma referência de padrão, uma implementação de algoritmo e uma capacidade RPKI de ponta a ponta são diferentes níveis de maturidade. A governança deve recompensar a publicação de tais lacunas. Suprimi-las para manter o ímpeto aumentaria o risco de uma data obrigatória frágil.

A proposta também identifica chaves e assinaturas maiores como preocupações para repositórios e validação. ML-DSA-65 é selecionado como candidato porque tem um padrão NIST finalizado e identificadores estáveis de certificado IETF e CMS, não porque é sempre a escolha mais pequena ou mais rápida. SLH-DSA oferece diversidade criptográfica, mas pode impor assinaturas significativamente maiores ou custos de assinatura mais altos, dependendo da variante. Outros candidatos podem oferecer vantagens de tamanho, mas carecem de perfil e maturidade de implementação equivalentes.

O NRS deve tratar o rascunho como um convite para medição compartilhada. Pode financiar implementações independentes, testes de repositório, ensaios de hardware e comparação de validadores sem declarar um vencedor. Os resultados devem incluir falhas e detalhes do ambiente. Um provedor que traz evidências úteis não deve receber controle exclusivo sobre a migração de produção como recompensa.

A seleção de algoritmo precisa de um padrão público de evidências

A suíte selecionada deve atender a critérios criptográficos, operacionais e institucionais. Os critérios criptográficos incluem base de segurança, força dos parâmetros, resistência à implementação, requisitos de aleatoriedade, comportamento de canal lateral, comportamento de falha e diversidade em relação a outras suítes aceitas. A existência de um padrão formal é necessária para confiança, mas não elimina o risco de implementação.

Os critérios operacionais incluem tamanho da chave pública e da assinatura, crescimento do certificado e da lista de revogação, tamanho do manifesto, instantâneos e deltas do repositório, latência de assinatura, CPU e memória do validador, tamanho do cache, tratamento de falhas e disponibilidade de hardware. As medições devem usar repositórios globais representativos, bem como casos de borda sintéticos. Um resultado mediano pode ocultar uma falha para um pequeno validador ou um grande ponto de publicação.

Os critérios de interoperabilidade exigem que pelo menos duas implementações de AC independentes, múltiplos ambientes de repositório e principais implementações de parte confiável concordem em conjuntos completos de entidades válidas e inválidas. Os testes devem cobrir identificadores de algoritmo malformados, parâmetros não suportados, manifestos desatualizados, revogação inconsistente, suítes desconhecidas e ramos antigo-novo misturados. Aceitação significa comportamento de segurança consistente, não apenas verificação bem-sucedida de uma entidade de caminho feliz.

Os critérios institucionais incluem licenciamento, concentração de fornecedores, diversidade de hardware, suporte a exportação e renovação, disponibilidade entre regiões, custo para pequenos operadores e capacidade de substituir um provedor. Uma suíte teoricamente excelente pode criar risco de governança se um único fornecedor controlar o hardware utilizável ou apenas um serviço puder operar o formato de chave necessário. As evidências de aquisição devem acompanhar as evidências de desempenho.

Os critérios devem ser definidos antes de comparar algoritmos favorecidos. Caso contrário, as instituições podem selecionar métricas que justifiquem um investimento existente. O NRS deve publicar pesos, métodos de teste, conjuntos de dados, exceções e conflitos de revisores. Os comentários da comunidade devem ser respondidos com razões. A recomendação final deve explicar por que as alternativas rejeitadas não foram escolhidas e que evidências poderiam provocar reconsideração.

A diversidade algorítmica é valiosa, mas não gratuita. Suportar múltiplas suítes aumenta a complexidade do código, configuração e depreciação. A RFC 7696 adverte que muitas escolhas podem prejudicar a interoperabilidade e deixar algoritmos fracos implantados por muito tempo. O objetivo é um conjunto pequeno e coerente com um caminho de substituição confiável, não um menu permanente que cada validador interpreta de forma diferente.

Equivalência semântica é o teste decisivo da migração

As entidades da suíte antiga e da nova não serão idênticas byte a byte. Chaves, assinaturas, números de série de certificados, detalhes de validade e caminhos de repositório podem diferir. A questão significativa é se produzem a mesma semântica de recurso e roteamento aceita. Para autorizações de rota, os validadores devem comparar as cargas úteis validadas resultantes por prefixo, comprimento máximo, AS de origem e contexto de confiança relevante.

Se os ramos divergirem, um validador não deve mesclá-los silenciosamente. Suponha que o ramo RSA autorize uma origem enquanto o ramo pós-quântico autorize outra, ou um ramo tenha revogado um certificado filho enquanto o outro permanece atual. Combinar os dois poderia ampliar a autoridade além de qualquer estado pretendido. Escolher o que validar primeiro pode ocultar um erro operacional grave ou ataque.

A divergência deve produzir telemetria explícita e uma resposta política limitada. Durante uma fase de teste inicial, a produção pode continuar a confiar na suíte estabelecida enquanto o novo ramo é investigado. Durante uma fase de nova suíte preferida, o fallback pode ser permitido para uma classe definida de falha técnica, mas não para um conflito semântico. A diferença entre não suportado, indisponível, malformado, expirado e contraditório deve permanecer visível.

A AC tem o dever de manter o estado correspondente entre os ramos durante a publicação paralela. Revogações, alterações de recursos e instruções do titular devem ser aplicadas consistentemente. A geração automatizada pode reduzir a deriva, mas a automação compartilhada também pode repetir um erro. Validadores independentes e monitores do titular devem comparar as saídas em vez de confiar em uma exibição administrativa comum.

As verificações semânticas devem se estender além das autorizações de rota. Conjuntos de recursos de certificado, status de revogação, cobertura do manifesto e inventário de entidades precisam de comparações correspondentes. Entidades assinadas mais novas e usos futuros podem exigir regras de equivalência específicas da entidade. O princípio orientador é estável: a migração muda a representação criptográfica, não a autoridade de recurso pretendida.

O NRS deve disponibilizar publicamente estatísticas de divergência de forma agregada. Os relatórios podem mostrar entidades não pareadas, saídas validadas inconsistentes, ramos desatualizados, eventos de fallback, divergências de validador e tempo para correção. Detalhes sensíveis do titular podem permanecer protegidos. Uma transição que reivindica sucesso enquanto esconde divergência semântica mediu a criptografia, mas não a segurança do roteamento.

A publicação paralela não deve se tornar um downgrade permanente

Executar duas suítes fornece um caminho de recuperação enquanto a nova amadurece. Também preserva o caminho vulnerável. Se os validadores aceitarem RSA indefinidamente sempre que o ramo pós-quântico estiver ausente ou inválido, um invasor pode suprimir o ramo mais forte e obter o resultado mais fraco. O fallback se torna um canal de downgrade quando suas condições são amplas, silenciosas ou permanentes.

Cada fase precisa de uma política de aceitação explícita. Na fase de teste, a suíte atual permanece autoritativa e a próxima suíte fornece evidências. Na fase de produção paralela, ambas devem estar presentes e ser semanticamente equivalentes. Na fase de preferência, a nova suíte governa, com fallback estritamente definido para falhas de disponibilidade. No fim da vida, a aceitação da suíte antiga cessa, exceto em contextos forenses ou de teste isolados.

O fallback deve ser limitado no tempo, registrado e visível para o operador. Um validador que cai repetidamente no fallback deve alertar em vez de normalizar a condição. Os operadores de âncora de confiança e AC devem receber sinais agregados para que possam distinguir uma falha de repositório de uma incompatibilidade sistêmica. Os titulares de recursos devem poder ver se seus produtos estão sendo aceitos em ambas as suítes.

A data de retirada deve ser baseada em evidências, mas confiável. Uma data que muda toda vez que um fornecedor está atrasado dá a cada fornecedor um incentivo para atrasar. Uma data que ignora uma incompatibilidade de hardware pode fragmentar a validação. A governança deve definir limites de prontidão, categorias de exceção e consequências com antecedência. Operadores críticos atrasados podem receber assistência limitada ou medidas de transição isoladas, não um veto indefinido.

Chaves e produtos antigos exigem retirada controlada. Removê-los muito cedo pode criar lacunas de validação; manter a capacidade de assinatura por muito tempo preserva a superfície de ataque. As ACs devem destruir ou arquivar chaves privadas antigas de acordo com um risco definido, remover material de confiança antigo na etapa declarada e reter evidências públicas suficientes para explicar o estado histórico. As evidências de retirada devem ser revisadas independentemente para ACs de alto nível.

A capacidade de desfazer a nova suíte é diferente de continuar a confiar na antiga para sempre. Um plano de substituição pode ativar outra suíte resistente, restaurar uma implementação anterior conhecida como boa ou suspender novas emissões enquanto os produtos válidos atuais persistem. A reversibilidade deve ser projetada como uma transição governada, não como uma exceção oculta que derrota o propósito de segurança.

A custódia das chaves deve permanecer portátil através de mudanças de hardware

As chaves privadas pós-quânticas podem exigir novas bibliotecas criptográficas, módulos de segurança de hardware, perfis de memória, cerimônias de assinatura e arranjos de backup. Essas mudanças criam uma oportunidade natural para os provedores agruparem custódia, publicação e suporte. O agrupamento pode reduzir o custo operacional. Também pode prender os titulares se a nova chave só puder ser usada através da conta de um único provedor ou de uma interface não documentada.

O NRS deve preservar a presunção de que um titular pode operar uma AC delegada ou nomear um provedor sob autoridade controlada pelo titular. A geração de chaves deve ocorrer dentro de um limite de segurança que o titular controla ou sobre o qual tem direitos contratualmente decisivos. O titular deve saber quem pode ativar a assinatura, como funcionam as aprovações, que evidências são retidas e como ocorre a substituição.

A exportação de chave privada nem sempre é desejável. Um dispositivo de hardware pode impedi-la deliberadamente. A portabilidade não pode significar que toda chave privada deve ser extraível. Isso significa que o relacionamento de certificação, os produtos públicos, a configuração, a evidência de auditoria e o serviço de publicação podem ser movidos, enquanto uma nova chave é gerada e certificada através de renovação coordenada. A não exportabilidade protege o material da chave; não confere propriedade ao operador do dispositivo.

Os provedores devem suportar interfaces comuns de solicitação de certificado, publicação e monitoramento. Wrappers de chave personalizados, escolhas de parâmetros não divulgadas e sistemas de aprovação proprietários não devem se tornar condições para participação no RPKI. Onde o suporte de hardware é escasso durante a implantação inicial, o NRS pode qualificar serviços compartilhados, mas os contratos devem incluir assistência à transição e nenhuma reivindicação sobre os recursos do titular.

Backup e recuperação requerem testes específicos do algoritmo. Alguns métodos de assinatura pós-quântica dependem criticamente de aleatoriedade segura. Hardware e software podem representar chaves de diferentes formas. As cerimônias de recuperação devem verificar se as chaves restauradas ou substituídas funcionam com codificações conformes e não repetem aleatoriedade insegura. A resposta mais segura a uma suspeita de comprometimento é tipicamente a substituição, em vez da recuperação da mesma chave de assinatura.

Pequenos operadores precisam de acesso financiado à migração segura. Se apenas grandes redes podem pagar por hardware e testes compatíveis, a custódia centralizada hospedada se tornará o padrão prático. O NRS pode fornecer subsídios, configurações de referência, cerimônias gerenciadas e ambientes de teste compartilhados utilizáveis com múltiplos provedores. O suporte deve seguir o membro, não subsidiar um hospedeiro dominante.

A capacidade do repositório é uma preocupação de governança

As assinaturas pós-quânticas podem ser muito maiores do que as assinaturas RSA atuais. A publicação paralela pode multiplicar certificados, listas de revogação, manifestos e entidades assinadas. As partes confiáveis sincronizam repetidamente o conteúdo global do repositório, validam-no e produzem saídas locais. Uma suíte que aumenta drasticamente a transferência ou o processamento pode afetar os operadores de forma desigual e criar nova concentração entre validadores de alta capacidade.

As medições devem cobrir instantâneos completos, atualizações incrementais, inicialização a frio, atualização comum, renovação em massa, eventos de revogação e recuperação após perda de estado local. O comportamento de instantâneo e delta RRDP é importante, assim como o fallback para outros métodos de recuperação. Os testes devem incluir redes restritas, regiões distantes e hardware comum, não apenas um laboratório bem conectado.

Os limites de tamanho de entidade e os controles de recurso devem evitar duas falhas. Limites muito frouxos podem permitir exaustão de memória, armazenamento ou processamento. Limites muito restritos podem rejeitar produtos pós-quânticos legítimos. Os validadores devem relatar se a rejeição veio de política algorítmica, sintaxe, tamanho, tempo, memória ou validação semântica. Um resultado genérico 'inválido' impede o diagnóstico e pode fragmentar a resposta do operador.

Os provedores de repositório não devem ganhar autoridade política simplesmente por absorver custos extras. Seu papel é publicar produtos conformes de forma confiável e sinalizar capacidade. As taxas podem refletir o custo mensurável do serviço, sujeito a transparência e concorrência. Um repositório não deve decidir que apenas sua AC afiliada pode usar a nova suíte ou atrasar a migração de um cliente para proteger um pacote de negócios.

As evidências de capacidade devem informar a escolha do algoritmo e o cronograma. Se ML-DSA produzir crescimento significativo, mas gerenciável, a engenharia e o investimento podem ser preferíveis a selecionar uma alternativa menos madura apenas pelo tamanho. Se as medições mostrarem que uma suíte proposta torna a validação global impraticável, o trabalho de padronização deve se adaptar. A decisão pertence à avaliação técnica aberta, não à negociação de contrato privado.

O NRS pode coordenar repositórios de teste compartilhados e publicar distribuições de desempenho anonimizadas. Deve separar os testes das âncoras de confiança e chaves de produção. Experimentos iniciais não devem vazar para a produção porque um operador reutiliza um caminho de repositório conveniente. A separação visual e técnica clara protege tanto a segurança quanto a credibilidade dos resultados.

A migração de emergência precisa de um modelo de poder mais restrito

Uma migração planejada permite anos de preparação. Uma emergência pode oferecer apenas semanas ou dias. O gatilho poderia ser evidências criptanalíticas confiáveis, um comprometimento de uma implementação amplamente utilizada, uma falha catastrófica de aleatoriedade ou uma falha na suíte pós-quântica selecionada após a implantação. Diferentes gatilhos exigem respostas diferentes; 'emergência quântica' não deve ser um cheque em branco.

A autoridade para declarar uma emergência deve ser distribuída. A evidência técnica pode vir de criptógrafos, mantenedores de implementação, órgãos de segurança nacional ou pesquisadores independentes. Os operadores de âncora de confiança e os corpos de padrões devem avaliar o efeito global. O NRS e outros órgãos de governança devem proteger a continuidade dos membros e evitar mudanças de serviço autointeressadas. Nenhum provedor de AC deve ser capaz de declarar uma emergência que force os clientes a seu produto.

Os poderes de emergência devem ser pré-especificados: acelerar um marco já testado, encurtar a validade do certificado, suspender determinadas emissões, exigir monitoramento aprimorado, ativar uma suíte alternativa resistente ou limitar o fallback. Cada ação deve indicar escopo, evidência, duração e revisão. A resposta deve evitar modificar o reconhecimento de recurso subjacente, a menos que o incidente desafie diretamente esse reconhecimento.

Uma renovação de chave de emergência pode ser tecnicamente válida, mas institucionalmente abusiva. Um pai poderia recusar um novo pedido do filho, insistir na custódia hospedada ou usar a emergência para retirar um recurso contestado. A revisão independente deve ser capaz de distinguir necessidade de segurança de alavancagem não relacionada. A continuidade temporária pode preservar um estado anterior incontestado enquanto a disputa prossegue.

A comunicação deve evitar falsa certeza. Se a evidência é preliminar, os operadores devem saber o que é conhecido, o que permanece desconhecido e quais ações protetivas são reversíveis. Ocultar a incerteza pode produzir reação excessiva descoordenada. Publicar detalhes operacionais sensíveis cedo demais pode aumentar o risco. Um plano de divulgação em várias camadas deve atender implementadores, operadores de rede, titulares e o público em níveis apropriados.

Toda ação de emergência deve terminar. Datas de término, revisão pós-ação, retirada de chaves e compensação por ação indevida devem ser definidas antes do uso. Uma autoridade de emergência que se torna controle comum transformaria o risco criptográfico em captura institucional.

Rollback é uma capacidade, não uma admissão de falha

As instituições às vezes evitam discutir rollback porque parece enfraquecer a confiança na suíte selecionada. O contrário é verdadeiro. Uma migração sem uma resposta segura a falhas de implementação, divergência semântica ou sobrecarga operacional depende do otimismo. A reversibilidade permite testes mais precoces enquanto limita as consequências de um erro.

Rollback não significa necessariamente reverter para RSA como resposta de produção. Antes do fim da vida da suíte antiga, o rollback limitado pode ser aceitável se a nova implementação falhar, mas o RSA permanecer dentro da janela de segurança declarada. Mais tarde, o rollback pode significar mudar para uma segunda suíte resistente, restaurar uma versão corrigida ou preservar o estado assinado atual enquanto a nova emissão é suspensa.

Os critérios de aceitação devem ser declarados antes de cada fase de produção. Exemplos incluem discordância do validador acima de um limite, divergência semântica, crescimento do repositório além dos limites testados, comportamento de hardware não suportado, aleatoriedade insegura, vazamento de chave ou incapacidade de revogar de forma consistente. Os critérios devem identificar quem ordena o rollback e como as evidências são preservadas.

Exercícios devem simular rollback parcial. Uma AC pode precisar reverter enquanto outras permanecem na nova suíte. Uma versão do validador pode ser defeituosa. Um repositório pode rejeitar uma entidade válida. A hierarquia de cima para baixo e o modelo de produto paralelo podem criar dependências que tornam a correção local difícil. Testar esses limites revela se a reversibilidade reivindicada existe na prática.

O caminho de retorno deve evitar autoridade dupla não controlada. As ACs precisam de manifestos ordenados, estado de revogação e chaves atuais claras. Os validadores precisam de política explícita e telemetria. Os titulares precisam de confirmação de que suas autorizações de rota pretendidas permanecem inalteradas. Chaves antigas ou novas chaves falhadas devem ser retiradas quando não forem mais necessárias, com evidências suficientes para revisão posterior.

O relatório público deve distinguir a causa do rollback da falha algorítmica. Uma má integração de biblioteca não prova que o primitivo criptográfico está quebrado. Um problema de capacidade de recurso pode exigir trabalho de arquitetura em vez de abandono. A classificação precisa protege o aprendizado técnico e impede que os provedores usem uma falha para desacreditar concorrentes sem evidências.

Três casos de migração revelam os riscos da governança

Considere uma grande AC delegada que controla seu próprio hardware e publicação. Ela participa de um piloto de produção depois que dois validadores independentes suportam a próxima suíte. O pai emite certificados correspondentes e o titular publica produtos semanticamente equivalentes em ambas as suítes. Monitores externos comparam saídas validadas. Após um intervalo medido, a nova suíte se torna preferida. O titular muda de fornecedor de hardware durante o piloto através de renovação normal, sem alterar seu status de recurso.

Este é um resultado forte porque a migração técnica e o movimento do fornecedor coexistem. O pai cumpre seu dever de certificação, o titular retém a custódia, os repositórios publicam ambos os ramos e os validadores expõem divergência. Nenhuma parte obtém uma reivindicação permanente por ter sido a primeira. A evidência, não o prestígio institucional, suporta o próximo marco.

Agora considere um pequeno operador usando assinatura hospedada. Seu provedor anuncia que o serviço pós-quântico requer um contrato de dez anos porque o hardware é caro e diz que a nova chave não pode ser movida. O NRS deve rejeitar a alegação de aprisionamento. O provedor pode cobrar taxas transparentes pelo serviço, mas o operador deve ser capaz de substituir a chave, mover a publicação e nomear outro hospedeiro qualificado. Uma chave não exportável é retirada através de renovação; o direito de recurso continua.

O terceiro caso é um conflito semântico. O ramo RSA contém uma autorização de rota estabelecida, enquanto o ramo pós-quântico a omite após um erro de publicação. Validadores que preferem a nova suíte classificariam a rota de forma diferente. O sistema deve alertar, impedir a mesclagem silenciosa e permitir fallback limitado enquanto a AC corrige o novo ramo. Recibos do titular e estado anterior ajudam a estabelecer a intenção. O incidente é revisado e incluído nas métricas de prontidão.

Mude os fatos mais uma vez: o novo ramo contém uma autorização adicional não presente no RSA. O fallback não pode resolver isso selecionando o resultado que mantém o tráfego estável. A autoridade adicional pode ser maliciosa ou errônea. A entidade afetada deve ser isolada, a evidência de assinatura e administrativa da AC examinada, e o titular contatado através de canais protegidos. A validade criptográfica não torna a semântica divergente legítima.

Esses casos mostram por que a migração não pode ser reduzida a identificadores de algoritmo. Os resultados decisivos são autoridade portátil, significado de roteamento consistente, falha observável e ação institucional verificável. Um sistema pode ser resistente à computação quântica e mal governado. Também pode ser institucionalmente justo, mas tecnicamente despreparado. A transição deve satisfazer ambos os testes.

O NRS deve adotar uma carta de defesa da migração 2025-2035

A carta deve começar com invariantes. O reconhecimento do recurso numérico não muda simplesmente porque a suíte de assinatura muda. O titular retém o direito à custódia autorizada e à escolha do provedor. As ACs não recebem novas reivindicações de propriedade. As partes confiáveis retêm uma escolha explícita de política de confiança. Os poderes de emergência são temporários, limitados e revisáveis.

A segunda parte deve definir portões de evidência técnica. Nenhuma suíte de produção obrigatória deve ser definida antes da interoperabilidade total de certificado, revogação, manifesto e autorização de rota em implementações independentes. As medições de repositório e validador devem cobrir escala representativa. As verificações de equivalência semântica, testes de entidade malformada, comportamento de downgrade e renovação devem passar nos critérios de aceitação publicados.

A terceira parte deve definir etapas e datas como intervalos antes de se tornarem compromissos. De 2025 a 2027, inventário, revisão de padrões e experimentos isolados dominam. De 2027 a 2030, hierarquias de teste interoperáveis e pilotos paralelos selecionados podem se expandir se as evidências os suportarem. A partir de 2030, a preferência de produção e a retirada clássica podem ser agendadas com base em evidências de segurança, prontidão do fornecedor e interoperabilidade global. O horizonte de 2035 deve motivar a conclusão sem afirmar que um cronograma serve para todos os contextos de confiança.

A quarta parte deve proteger a participação. Pequenos operadores recebem suporte de referência e serviço gerenciado portátil. Os provedores divulgam dependências e condições de saída. As obrigações do setor público são mapeadas sem criar raízes incompatíveis. Representantes dos membros, especialistas em segurança, implementadores e revisores independentes participam das decisões de marco. Conflitos de interesse são registrados.

A quinta parte deve definir autoridade de incidente e rollback. Classes de gatilho, órgãos de decisão, medidas temporárias, limites de fallback, comunicação, revisão e encerramento são aprovados antes da crise. Nenhuma emergência permite que uma AC resolva disputas de recursos não relacionadas. Compensação e correção se aplicam quando poderes excepcionais são abusados.

Finalmente, a carta deve exigir evidências anuais. O NRS relata cobertura de implementação, diversidade de hardware, crescimento do repositório, tempo de validação, divergência de ramos, fallback, sucesso de renovação, concentração de fornecedores, prontidão de pequenos operadores e riscos não resolvidos. As métricas devem mostrar distribuições e testes falhos, não apenas uma porcentagem marcada como pronta.

A migração só tem sucesso se os usuários puderem sair

As transições criptográficas concentram naturalmente a expertise. O hardware inicial é escasso, as bibliotecas são desconhecidas, os padrões mudam e os erros operacionais podem ser custosos. Alguns provedores podem se tornar indispensáveis. É precisamente neste momento que os direitos de saída devem ser mais fortes, porque a dependência formada durante a transição pode persistir muito depois de a tecnologia amadurecer.

Cada serviço pós-quântico qualificado deve oferecer onboarding documentado, exportação de evidências, portabilidade de publicação, renovação de chave substituta, rescisão e cooperação em incidentes. O contrato deve afirmar que certificados e produtos assinados são executados para o titular reconhecido, não propriedade do serviço. Mudanças significativas de preço ou aquisição do provedor devem desencadear uma janela de movimentação razoável.

O NRS deve testar a saída anonimamente. Um cliente sintético pode se mover de um serviço hospedado para outro, de operação hospedada para delegada e de um fornecedor de hardware para outro. O teste observa a resposta do pai, a continuidade do repositório, a equivalência semântica, a retirada de credenciais e a convergência do validador. Um provedor que pode assinar, mas não pode liberar um cliente, não está totalmente qualificado.

A concorrência deve incluir capacidade de continuidade. Se um serviço dominante falhar, provedores alternativos devem ter hardware, pessoal e capacidade de repositório suficientes para aceitar migrações em ondas. A capacidade de reserva pode ser testada sem atribuir recursos ativos. Mapas de dependência devem revelar se alternativas aparentes usam o mesmo módulo criptográfico, controle de nuvem ou equipe de suporte.

A escolha do usuário não é absoluta. Um titular não pode exigir um algoritmo não padronizado, gerenciamento de chave inseguro ou aceitação indefinida da suíte antiga. A Sociedade pode impor resultados de segurança comuns. O teste de legitimidade é se os requisitos são neutros em relação ao fornecedor, baseados em evidências, corrigíveis e não mais amplos do que o necessário para interoperabilidade e segurança.

Sair é a evidência mais forte de que o papel técnico de uma AC não se tornou uma reivindicação de ativo. Se o titular pode gerar uma chave substituta, obter certificação correspondente, mover a publicação e preservar a semântica de roteamento sob um novo serviço qualificado, a hierarquia coordenou a segurança sem confiscar a escolha.

A governança deve permanecer adaptável após a transição quântica

A migração pós-quântica não será a última mudança criptográfica. Os algoritmos podem enfraquecer, as implementações podem falhar, o hardware pode se concentrar e as suposições operacionais podem envelhecer. O objetivo duradouro não é uma única passagem bem-sucedida do RSA para uma suíte favorita. É um sistema capaz de mudar novamente sem crise ou captura.

Essa capacidade depende de limites de abstração limpos, formatos interoperáveis, política algorítmica explícita, chaves portáteis ou renovação, capacidade de repositório, monitoramento semântico e direitos de decisão praticados. Também depende de memória institucional. Evidências de pilotos iniciais, testes falhos, ações de emergência e mudanças de fornecedor devem ser preservadas para que futuros líderes não repitam erros evitáveis.

O NRS deve separar a política algorítmica da política de serviço comercial. Uma atualização técnica pode revisar suítes aceitas sem reescrever direitos de associação. Uma qualificação de fornecedor pode mudar sem modificar o padrão. Uma disputa de titular pode ser adjudicada sem escolher uma arquitetura criptográfica. A separação reduz a probabilidade de que uma questão urgente carregue poder não relacionado com ela.

A revisão independente deve continuar após o fim da vida da suíte antiga. Os revisores devem verificar se as chaves antigas foram retiradas, validadores não suportados permanecem ausentes, exceções de fallback não são persistentes, o novo mercado não está concentrado e os titulares ainda podem se mover. Uma declaração de conclusão não deve encerrar a observação.

A Sociedade também deve reter humildade sobre a palavra 'seguro'. Os algoritmos pós-quânticos são projetados para resistir a ataques clássicos e quânticos conhecidos sob análise atual. Eles não são garantias contra qualquer descoberta futura, canal lateral, erro de implementação ou abuso administrativo. Alegações precisas preservam melhor a confiança do que linguagem absoluta.

O sucesso da governança será visível quando a próxima mudança de algoritmo for rotineira: os padrões amadurecem abertamente, implementações independentes interoperam, os titulares retêm autoridade, os provedores competem, os validadores expõem diferenças e as chaves antigas são retiradas com base em evidências. A migração quântica é o caso de teste para essa capacidade duradoura.

Uma chave mais forte não deve criar uma instituição mais forte do que os membros autorizaram

O período até 2035 convidará declarações dramáticas. Alguns preverão colapso quântico imediato; outros descartarão a preparação como especulativa. A posição responsável está entre eles. O RPKI deve construir e testar um caminho pós-quântico agora porque as migrações globais levam anos e uma falha criptográfica poderia afetar a confiança no roteamento. Deve manter as datas obrigatórias condicionais a evidências completas porque a implantação prematura pode criar seu próprio risco sistêmico.

A hierarquia técnica é inevitável. As ACs pai devem estar prontas, os repositórios devem carregar novas entidades e as partes confiáveis devem validá-las. A hierarquia institucional é uma escolha. O sistema pode coordenar essas funções sem conceder a uma AC custódia permanente, controle proprietário ou veto sobre o movimento do cliente. Direitos claros e renovação interoperável transformam a hierarquia em serviço, não em propriedade.

O registro de padrões já fornece fundações úteis. A RFC 6916 fornece um modelo por fases de vários anos. A RFC 7696 explica por que a agilidade algorítmica requer mais do que identificadores e por que muitas escolhas podem enfraquecer a interoperabilidade. O NIST padronizou assinaturas pós-quânticas confiáveis. As especificações de certificado e CMS do IETF agora suportam ML-DSA. O trabalho atual do RPKI identifica tanto um candidato plausível quanto questões de implementação não resolvidas.

A tarefa restante é a governança sob incerteza. O NRS deve definir quem decide, que evidências contam, como a discordância é tratada, quando o fallback termina, como o rollback funciona e que direitos sobrevivem a cada etapa. Deve medir consequências em repositórios e validadores, apoiar pequenos membros e evitar que a concentração de fornecedores se torne política.

Uma chave privada mais longa ou mais complexa não confere um direito maior. Um novo certificado não cria uma nova alocação. Uma AC que coordena a migração não adquire o recurso. Um provedor que armazena a chave não possui o relacionamento de certificação. Essas proposições devem ser escritas antes que infraestrutura cara e retórica de emergência tornem mais difícil defendê-las.

A migração quântica terá sucesso quando a criptografia mudar e a distribuição legítima de poder não mudar. O titular permanece reconhecido, a AC permanece responsável, o validador permanece explícito, o provedor permanece substituível e o padrão permanece aberto a evidências. Isso não é um obstáculo à segurança do roteamento. É a condição de governança que torna a segurança de roteamento mais forte digna de confiança.

Evidências e leitura adicional