Resumo

  • A rejeição prometida por rpki-client não chegou como um único evento em 18 de agosto: a mudança daquele dia preparou a versão 9.9, mas o ramo relevante continuou alertando sem rejeitar.
  • O último release portable permanecia 9.8 em 21 de agosto; ao mesmo tempo, uma console rpki-client independente processava objetos AFRINIC e mostrava outros erros sem registrar o antigo alerta de nomes X.509.
  • A evidência descreve uma transição de compatibilidade controlada, não uma virada instantânea nem uma queda. Antes de alterar política ROV, aviso, fonte, release e implantação devem ser lidos como relógios separados.

Um prazo virou quatro relógios operacionais

Em fevereiro, o cronograma parecia inequívoco. Job Snijders, mantenedor de rpki-client, informou ao Database Working Group da AFRINIC que, a partir de terça-feira, 18 de agosto de 2026, a implementação rejeitaria certificados cujos nomes X.509 de emissor ou sujeito não usassem PrintableString no atributo commonName. A AFRINIC havia estabelecido 31 de julho como meta para eliminar os objetos restantes. Se não conseguisse, dizia o alerta, membros afetados poderiam enfrentar impacto no serviço RPKI. A mensagem pública registra a promessa e o risco.

No dia 18, o repositório upstream recebeu o commit Prepare for rpki-client 9.9 release. O número da versão passou de 9.8 para 9.9. A semelhança com a data anunciada, porém, não deve esconder o que o código faz.

Na função valid_printable_string(), um commonName que não seja PrintableString ainda gera apenas um aviso quando o programa roda com verbosidade extra. O return 0 que faria a validação falhar permanece dentro de #if 0, portanto fora do binário compilado. Esse é o estado do arquivo no próprio commit da versão 9.9.

Também não havia um release portable 9.9 publicado em 21 de agosto. Na página de releases do projeto, a versão mais recente continuava sendo a 9.8, de abril. Mudar uma macro no fonte, publicar um artefato assinado, distribuir um pacote e instalá-lo em produção são marcos diferentes. A rejeição não pode ser dada como executada só porque o calendário chegou ao dia previsto.

A data era apenas o relógio do aviso. O relógio do código mudou de número sem ativar a rejeição; o do release não se moveu; e o da implantação só podia ser lido em validadores independentes e pacotes downstream.

Um validador independente mostrou o quarto relógio

A console rpki-client independente forneceu a observação mais útil do estado implantado. Sua execução de 21 de agosto mostrava rpki-client -c -j buscando e validando o conjunto mundial de repositórios, inclusive material da AFRINIC. A partir de 08:33 UTC, registrou lacunas de sequência em dois manifests AFRINIC e depois dois ROAs AFRINIC expirados.

O log não escondia erros. Ainda assim, não exibia o antigo aviso sobre nomes de emissor ou sujeito diferentes de PrintableString. A observação é mais independente que um relatório do emissor, mas continua sendo a ausência de uma mensagem no log de uma implementação, não um censo criptográfico de cada certificado AFRINIC.

A conclusão defensável é operacional, não triunfal. O prazo passou sem que o ramo de rejeição aparecesse no código fixado, enquanto um validador independente continuou processando material AFRINIC e expôs defeitos diferentes. O padrão é compatível com menor exposição ao legado, mas não estabelece quando o último objeto foi reemitido nem se todas as implementações concordam.

Os ROAs expirados e as lacunas de sequência de manifest observados na console são problemas distintos, sem evidência que os ligue ao antigo uso de UTF8String.

Corrigir a configuração não corrigia o passado

O requisito técnico está na seção 4.5 do RFC 6487. O commonName usado nos nomes de certificados de recursos deve ser codificado como PrintableString. Depois de uma atualização do sistema RPKI em 2022, a plataforma hospedada da AFRINIC passou a emitir esses valores como UTF8String.

Na explicação publicada em março de 2024, a AFRINIC associou o comportamento a uma configuração atualizada do OpenSSL. A documentação induzia a uma compreensão errada do padrão efetivo. Uma correção na documentação do OpenSSL esclareceu que utf8only era o valor usado por padrão e que nombstr restringia a saída a tipos compatíveis com PrintableString.

Ajustar a assinatura resolveu novas emissões. Não alterou certificados e objetos já assinados. Para eliminar o passivo, era necessário fazer rekey das CAs hospedadas afetadas e reemitir os objetos dependentes. A AFRINIC planejou executar o trabalho em lotes para reduzir o risco de inconsistências nos pontos de publicação e tratar com cuidado membros que mantinham muitos certificados de entidade final.

Essa é a diferença entre uma regra determinística e uma migração operacional. A regra cabe em uma condição. A migração atravessa chaves, certificados, manifests, ROAs, caches e coordenação com membros. A AFRINIC controlava a emissão; os mantenedores controlavam a exceção; distribuidores e operadores controlavam a implantação. Nenhum desses atores podia sincronizar os demais por anúncio.

Seis mil anúncios eram uma hipótese de estresse

Em 17 de novembro de 2025, Snijders relatou 988 objetos com nome de emissor não conforme e 657 com nome de sujeito não conforme. Se a exceção fosse removida naquele momento, estimou, os VRPs únicos sob o trust anchor da AFRINIC cairiam temporariamente de 21.027 para 19.480. Cerca de 6 mil anúncios BGP passariam de ROV valid para not-found até a reemissão dos ROAs. A mensagem contém os números e suas condições.

O cálculo não dizia que esses anúncios já tinham mudado. Tampouco not-found significa invalid ou inacessível. Significa que o anúncio deixa de contar com aquele registro de autorização de origem validado.

Nada nas fontes públicas examinadas demonstra que a transição projetada ocorreu em agosto de 2026. Não há base para transformar o número de 6 mil em estatística de incidente. O uso correto é como teste de estresse: ele quantificou o que aconteceria se a tolerância acabasse antes da reemissão.

O mesmo número também mostrou por que a exceção não poderia ser permanente. Enquanto os objetos existiam, removê-la transferia o custo do erro de emissão para detentores de recursos. Mantê-la indefinidamente, depois da correção, transferiria o custo para todos os usuários e revisores do validador. A ordem das ações, não uma escolha entre conformidade e continuidade, era a solução.

A sequência segura reparou a camada compartilhada primeiro

Se o validador ficasse estrito primeiro, objetos conhecidos deixariam de produzir VRPs, e os membros fariam a correção sob pressão. O software estaria mais próximo do texto normativo, mas a rede pagaria a passagem.

Se o emissor corrigisse primeiro o caminho de assinatura, renovasse as CAs hospedadas, reemitisse objetos e comprovasse o esgotamento do conjunto problemático, a retirada posterior da exceção seria uma normalização de baixo risco.

Os sinais de 21 de agosto apontam para essa segunda sequência. A console independente processava objetos AFRINIC sem mostrar o antigo alerta, enquanto o código fixado de rpki-client ainda tolerava o tipo. É melhor do que o estado inverso, no qual código estrito encontraria um repositório cheio de legado.

Isso não legitima uma exceção perpétua para uma única RIR. Código especial amplia a superfície de revisão e torna o comportamento entre validadores menos uniforme. Depois que observações independentes confirmarem a ausência dos objetos, a exceção deve poder sair com muito menos risco.

O prazo pode ter funcionado não como um flag day, mas como instrumento de coordenação. Tornou explícito o custo da demora e deu credibilidade ao fim da tolerância. Se isso acelerou a reemissão antes da mudança do código, produziu um resultado melhor do que uma rejeição pontual no dia anunciado.

O que ainda precisa de comprovação

As fontes públicas não informam a hora exata da última reemissão, quantas CAs hospedadas foram renovadas na etapa final nem quais implementações independentes participaram da validação de encerramento. Em janeiro, uma discussão citou planos da AFRINIC para publicar instruções, comunicar membros e abrir um helpdesk; participantes observaram que faltava um cronograma. O registro comprova o plano, não a conclusão de cada atividade.

A console pública de rpki-client é apenas um ponto de observação. Ela prova que uma execução independente processava objetos AFRINIC e informava outros erros; não prova que cada objeto estava conforme nem que Routinator, Fort ou todos os pacotes downstream obtiveram o mesmo resultado. Do lado do software, a rejeição continuava desativada no commit de 18 de agosto, e 9.8 era o último portable publicado em 21 de agosto.

Dentro desses limites, a notícia é clara: uma data não encerra a migração. A Primazia do Código em Execução de Lu Heng oferece a hierarquia correta — mudança se torna realidade por implementação, validação, implantação e adoção. Em 21 de agosto, os quatro relógios descreviam uma lacuna de compatibilidade administrada, não o único interruptor prometido em fevereiro.