Resumo

  • A RFC 9598 coloca uma caixa cuja parte local contém caracteres não ASCII em SmtpUTF8Mailbox, dentro de um otherName X.509; uma parte local somente ASCII continua em rfc822Name, mesmo quando o domínio é internacionalizado.
  • O domínio vira um A-label IDNA2008 em minúsculas. A parte local UTF-8 não recebe dobramento de caixa, normalização Unicode nem mapeamento de compatibilidade; depois do preparo do domínio, a comparação é feita octeto por octeto.
  • Um nome correspondente é apenas o recibo de uma comparação. Validade do caminho, restrições de nome, finalidade, controle atual da caixa, rota SMTPUTF8, autorização local e efeito observado precisam de evidências próprias.

O chamado chega ao suporte como um problema de aparência. O certificado mostra uma caixa; o cadastro de e-mail mostra outra; na tela, ambas parecem iguais. A equipe encontra uma função Unicode capaz de produzir a mesma forma normalizada e propõe “corrigir” o valor na borda, sem reemitir o certificado e sem alterar a caixa provisionada.

Essa solução resolve o chamado ao preço de uma decisão de identidade. A função passa a dizer que duas sequências de bytes, registradas por autoridades diferentes, nomeiam o mesmo sujeito. Uma atualização da biblioteca pode ampliar ou reduzir essa equivalência depois. Nenhuma assinatura protege a transformação, e nenhum operador consegue reconstruir a comparação original apenas olhando o texto renderizado.

A RFC 9598 impede que a conveniência seja confundida com competência. Ela atribui ao domínio uma preparação IDNA2008 específica e exige que a parte local permaneça intacta. A assimetria não é uma imperfeição: é o mecanismo que impede o aplicativo consumidor de assumir o papel do emissor do certificado e do provedor da caixa postal.

A escolha da forma começa à esquerda do sinal de arroba

O registro do RFC Editor e o IETF Datatracker identificam a RFC 9598 como Proposed Standard de maio de 2024. Ela atualiza o perfil PKIX da RFC 5280 e torna obsoleta a RFC 8398.

O rfc822Name tradicional comporta uma caixa ASCII, mas não uma parte local internacionalizada. Para preencher essa lacuna, a RFC usa a extensão otherName de GeneralName e define SmtpUTF8Mailbox, com o identificador 1.3.6.1.5.5.7.8.9. A atribuição consta do registro IANA SMI Numbers.

É a parte local que escolhe a forma. Havendo qualquer caractere não ASCII nela, o certificado deve usar SmtpUTF8Mailbox. Sendo ela inteiramente ASCII, deve usar rfc822Name, ainda que o domínio tenha uma forma internacionalizada. As duas representações pertencem ao mesmo espaço de nomes de e-mail, mas não são alternativas escolhidas por preferência de implementação.

Isso muda o inventário operacional. Um coletor que só indexa rfc822Name deixa caixas internacionalizadas invisíveis. Um emissor que usa SmtpUTF8Mailbox para uma parte local ASCII cria um artefato fora do contrato. Um gateway que converte a tag depois da leitura pode apresentar um objeto de dados uniforme, mas destrói a prova de qual forma o certificado realmente assinou.

O conteúdo é uma caixa de envelope, não um endereço de exibição. Não inclui frase, comentário ou par de sinais angulares. SmtpUTF8Mailbox é um UTF8String ASN.1 não vazio, e sua codificação UTF-8 não pode conter marca de ordem de bytes. A fronteira da codificação vem da RFC 3629; o contexto de cabeçalhos internacionalizados é delimitado pela RFC 6532.

O domínio tem um procedimento de preparo

A metade do domínio segue IDNA2008. A RFC 5890 fornece o vocabulário de A-label, U-label e LDH; a RFC 5891 fornece as conversões de protocolo. A RFC 9598 exige conformidade IDNA2008 dos domínios de e-mail em certificados X.509, sem transformar os mapeamentos discutidos pelo arcabouço em atalhos locais.

Dentro de SmtpUTF8Mailbox, um rótulo de domínio não ASCII é armazenado como A-label, nunca como U-label. Rótulos ASCII obedecem às restrições NR-LDH. Letras nos A-labels e NR-LDH aparecem em minúsculas. O certificado oferece, portanto, uma forma única de comparação; o validador de caminho não precisa voltar à apresentação Unicode para decidir o nome.

Quando o valor candidato vem de um formulário, de uma mensagem ou de um diretório, há um preparo limitado. O software remove frase, comentário e sinais angulares, converte U-labels do domínio em A-labels e coloca em minúsculas as letras apropriadas do domínio. Então para. Essa é uma canonização com objeto e alcance definidos, não uma licença para limpar a caixa inteira.

A uniformidade dos A-labels é a principal correção em relação à RFC 8398, que permitia A-label ou U-label conforme a situação. O novo documento não prova que todos os emissores e consumidores já implantaram o comportamento. Ele fornece algo mais útil para a operação: um resultado que pode ser verificado byte a byte e uma falha que pode ser atribuída a uma etapa.

A parte local não recebeu uma regra universal de equivalência

A parte local pertence ao modelo de e-mail internacionalizado da RFC 6530 e à extensão SMTP da RFC 6531. Ela é codificada em UTF-8. Isso não transforma UTF-8 em um cadastro universal que diga quais caixas são a mesma, tampouco delega ao consumidor do certificado a política interna do provedor de e-mail.

Por isso, a RFC 9598 proíbe transformações nessa parte. Não há dobramento de maiúsculas e minúsculas. Não há normalização Unicode. Não há mapeamento de compatibilidade. Após o preparo do domínio, a caixa resultante é comparada octeto por octeto. Dois valores SmtpUTF8Mailbox já codificados não precisam de preparo: equivalem somente se todos os bytes forem iguais.

Um SmtpUTF8Mailbox e um rfc822Name nunca correspondem. O primeiro exige parte local não ASCII; o segundo não pode contê-la. Traduzir uma forma na outra depois da leitura não melhora a compatibilidade. Apenas introduz uma relação de identidade que o certificado não declarou.

A consequência humana é incômoda: duas grafias que parecem iguais podem ser rejeitadas. Esse custo é consciente. Se a autoridade certificadora codificou uma sequência e o sistema de correio provisionou outra, um mismatch preserva a divergência para investigação. A normalização silenciosa a apaga e permite que a versão da biblioteca, o sistema operacional ou a configuração regional mude a identidade efetiva depois da emissão.

Busca aproximada e apresentação amigável continuam válidas em suas próprias camadas. Elas podem sugerir ao operador que há um provável erro de provisionamento. Não podem alimentar diretamente a decisão criptográfica. A tela é uma projeção; os bytes assinados e os bytes provisionados são os registros de autoridade.

Restrições de nome controlam escopo de emissão

As duas formas pertencem ao mesmo espaço de nomes. Uma autoridade certificadora subordinada que já estava limitada a um domínio por restrições rfc822Name não deve escapar dessa fronteira ao emitir um otherName novo.

A RFC 9549 atualiza as regras PKIX internacionalizadas para que restrições rfc822Name alcancem ambas as formas. O certificado da CA expressa a restrição de e-mail como rfc822Name conforme IDNA2008, em A-label. Na comparação, prepara-se o domínio do sujeito, retira-se a parte local e executa-se teste exato de host ou de sufixo de domínio. Restrições para uma caixa específica não devem ser usadas.

O resultado responde se aquele domínio estava dentro do espaço no qual a CA subordinada podia emitir. Não cria uma caixa, não verifica se ela ainda existe, não demonstra que o sujeito a controla e não decide se a chave serve para a ação solicitada. Uma política de emissão pode estar correta enquanto a política de acesso rejeita o certificado.

Um recibo de validação completo separa pelo menos quatro fatos: o artefato carregava a forma GeneralName e os bytes esperados; a comparação de caixa obedeceu ao algoritmo da RFC 9598; o caminho e as restrições aplicáveis passaram sob a política de confiança escolhida; a aplicação aceitou o certificado para uma finalidade declarada. Nem a soma desses fatos comprova que um caminho SMTPUTF8 entregou uma mensagem.

A entrega e a autorização estão depois da comparação

SMTPUTF8 é uma capacidade de transporte distinta. A RFC 6531 permite que participantes SMTP anunciem e usem endereços de envelope internacionalizados. O certificado pode corresponder à caixa quando o próximo relay não oferece a extensão. Uma mensagem também pode percorrer uma rota SMTPUTF8 funcional sem qualquer certificado RFC 9598.

O controle atual exige outra observação. A CA pode ter validado um endereço segundo sua prática, mas o consumidor ainda precisa do trust anchor pretendido, do caminho efetivo, da política, do uso de chave, do estado de revogação, do vínculo da aplicação e da regra de permissão vigente. A assinatura pode validar e a ação continuar proibida. A mensagem pode ser aceita e não lida. O login pode funcionar e a alteração subsequente fracassar.

O ensaio de Lu Heng sobre a primazia do código em execução oferece um critério direto. Dizer que um produto “suporta RFC 9598” não basta. É preciso um rastro que preserve bytes do certificado, saída do parser, domínio externo antes e depois do IDNA, parte local intacta, comparação, caminho, restrições, decisão de política, ação e efeito.

A lente da especificação inicial mínima explica o desenho estreito: padronizar uma forma, uma representação do domínio e um algoritmo de comparação sem centralizar provisionamento, evidência da CA, permissão da aplicação e transporte. A análise das camadas da realidade completa a disciplina: nome representado, nome correspondente, certificado válido, caixa controlada, ação autorizada e efeito observado são registros relacionados, não sinônimos.

A decisão de liderança é retirar da central de suporte a obrigação impossível de resolver todas essas camadas com uma alteração de texto.

Fontes