Resumo

  • O RIPE Database 1.123 aplica NFC ao Unicode decomposto em descr: e remarks: antes de sanear caracteres de controle e executar a conversão IDNA.
  • A normalização é uma defesa legítima de interoperabilidade, mas a sequência enviada, a representação canônica e os bytes emitidos por uma interface continuam sendo provas diferentes.
  • Um registro de transformação, protegido contra exposição indevida, pode ligar essas etapas sem publicar texto livre, credenciais ou dados pessoais.

A tela mostra uma letra; o sistema recebe uma sequência

O teste público usa o nome Ondřej Caletka. O ř pode ser o caractere pré-composto U+0159. Também pode ser formado por r, U+0072, seguido do caron combinante U+030C. As duas formas devem representar o mesmo caractere abstrato. Uma comparação binária antes da normalização, porém, encontra cadeias distintas.

O commit incorporado ao Whois 1.123 deixa a transformação auditável. Ele cria uma instância NFC da biblioteca ICU. Em createUtf8Attribute, o software remove os escapes Java do valor, aplica a normalização, percorre os pontos de código resultantes, saneia caracteres de controle e só então faz a conversão IDNA já existente.

A nova prova automatizada envia U+0072 U+030C por um atributo descr: e exige uma string Java de comprimento um. Outra asserção parte de Ondřej Caletka com o r decomposto e exige Ondřej Caletka com o único U+0159. Portanto, não se trata de uma fonte tipográfica escolhida pelo navegador; a composição integra o caminho do valor.

As notas oficiais datam a entrada da versão 1.123 em produção em 8 de julho de 2026. O escopo declarado é o Unicode decomposto em descr: ou remarks:. A documentação atual de codificação também identifica esses dois campos livres como os atributos que aceitam UTF-8 e informa que a normalização é NFC.

A defesa mais forte favorece a NFC

O Unicode Standard Annex #15 define NFC como decomposição canônica seguida de composição canônica. Seu ganho principal é fazer com que cadeias canonicamente equivalentes tenham o mesmo resultado normalizado. O teclado ou editor de origem deixa de transformar um acento combinante em uma diferença binária permanente diante da forma pré-composta.

Chamar esse processo de adulteração seria perder a finalidade. A equivalência canônica do texto é preservada. NFC também não equivale a uma normalização de compatibilidade aplicada sem critério, que apagaria um conjunto maior de diferenças. Para dados de registro consumidos por clientes heterogêneos, a convergência é uma medida de resiliência.

O RIPE NCC começou de maneira limitada. O Whois 1.122, em produção desde 30 de abril, liberou UTF-8 somente em descr: e remarks:. A proposta ao Database Working Group descreveu um mínimo viável: permitir avisos no idioma local e ganhar experiência sem internacionalizar nomes, endereços ou campos de dados pessoais. Ela também advertiu que informações pessoais não devem ser colocadas nesses atributos livres.

O controle adequado não é obrigar o banco a usar a forma decomposta como registro principal. É tornar possível reconstruir qual entrada foi recebida, qual regra produziu a forma canônica e qual representação saiu por um serviço.

A interface acrescenta outra fronteira

A página Character Encoding diferencia as saídas. Whois na porta 43, NRTMv3 e os arquivos diários comuns usam Latin-1 por padrão. Um caractere não suportado pela interface é substituído por ?. A aplicação web, a API REST do Whois, RDAP, NRTMv4, Syncupdates e os arquivos .utf8.gz usam UTF-8 por padrão. Na porta 43, o cliente pode pedir outro charset.

A compatibilidade histórica e a preservação moderna de Unicode são objetivos legítimos. Mesmo assim, o objeto arquivado de uma saída Latin-1 não é uma cópia byte a byte do valor canônico em UTF-8. Um ponto de interrogação produzido no momento da entrega não é prova de que o atualizador enviou esse caractere.

Essa diferença afeta trabalhos comuns. Um espelho calcula o hash do fluxo recebido. O operador guarda a confirmação de uma mudança. Um auditor compara um dump antigo com uma resposta REST. Sem o nome da representação, uma divergência pode parecer mudança substantiva quando foi codificação ou NFC. E duas telas iguais podem esconder que as entradas originais tinham sequências diferentes.

As fontes não afirmam que um espelho específico cometeu esse erro. Também não mostram que todos os objetos anteriores à versão 1.123 foram normalizados em massa, nem se a entrada anterior à NFC é preservada internamente em todos os casos. A análise não deve inventar respostas. Basta reconhecer a transformação deliberada e exigir que a prova diga de qual lado ela foi produzida.

Como registrar sem publicar o campo livre

No ingresso, um registro mínimo pode identificar objeto e versão, confirmação da operação, classe do atributo, interface e charset de entrada. Deve nomear NFC, versão ou commit do software, informar se a sequência de pontos de código mudou e classificar eventuais substituições por saneamento ou validade do repertório.

A vinculação de integridade precisa respeitar a privacidade. O hash público de um texto curto e previsível pode ser descoberto por tentativa. Um compromisso autenticado, um hash de lote sob controle de acesso ou uma prova disponível apenas a partes autorizadas é mais seguro. Não há motivo para colocar descr:, remarks:, chaves de atualização ou dados pessoais no registro público.

Na entrega, acrescentam-se a interface de consulta ou replicação, o charset solicitado, a versão de serialização e o resumo criptográfico dos bytes efetivos. Correções futuras recebem uma relação de substituição. Assim, o sistema preserva três nomes: enviado, canônico e emitido.

Esse mecanismo não torna verdadeira a frase armazenada. Um remarks: normalizado não identifica o operador da rede; um descr: não demonstra propriedade do recurso nem comportamento atual de roteamento. O registro comprova somente a transformação entre representações. Esse limite protege a função de ledger sem transformar o RIPE NCC em árbitro de fatos que não controla.

Limites desta apuração

Nenhuma fonte citada documenta queda, ataque, falha de autorização, troca de identidade ou dano causado pela NFC. O material não diz que todo atributo RPSL aceita UTF-8, nem que person:, role:, org-name: ou endereços foram internacionalizados. O commit isolado também não permite descrever o destino de cada objeto histórico.

O incidente de NRTM de agosto pertence a outra pauta: novas linhas adicionais, objeto RPSL inválido, interrupção do fluxo e mudanças na versão 1.124. Ele não será recontado aqui. Continuidade de replicação e custódia da representação Unicode precisam de provas separadas.

Fontes

  1. Notas de versão do RIPE Database
  2. Codificação de caracteres no RIPE Database
  3. Planos trimestrais arquivados do RIPE Database
  4. Atualização operacional do Database Working Group no RIPE 90
  5. Proposta de UTF-8 em descr: e remarks:
  6. Mensagem de lançamento do Whois 1.122
  7. Análise de impacto de UTF-8 no RIPE Labs
  8. Commit do RIPE-NCC para normalizar Unicode decomposto
  9. Releases do Whois publicados pelo RIPE-NCC
  10. Unicode Standard Annex #15