Resumen

  • Una parte local no ASCII se codifica como SmtpUTF8Mailbox en otherName; si la parte local sólo contiene ASCII, el certificado debe usar rfc822Name, aunque el dominio sea internacionalizado.
  • El dominio externo puede convertirse a A-label IDNA2008 y minúsculas. La parte local UTF-8 no admite normalización ni plegado de mayúsculas: la comparación final es byte por byte.
  • Coincidir con el nombre certificado no demuestra que el buzón exista, que el sujeto lo controle, que la ruta soporte SMTPUTF8, que el certificado sirva para esa operación ni que la acción haya producido un resultado.

Pensemos en una pasarela de identidad que recibe una dirección escrita por el usuario y un certificado de cliente. Antes de una actualización, las dos partes locales no coinciden. Después, una nueva función de normalización las convierte en una misma cadena visible y la pasarela acepta el acceso. Los certificados no cambiaron. Las cuentas tampoco. Cambió el poder de la biblioteca para decidir qué identidades eran equivalentes.

RFC 9598 impide esa simplificación. El dominio y la parte local se parecen porque están separados por una arroba, pero no comparten autoridad de comparación.

El tipo X.509 depende de la parte local

El registro del RFC Editor y el Datatracker describen RFC 9598 como estándar propuesto de mayo de 2024. Actualiza RFC 5280 y deja obsoleto RFC 8398.

rfc822Name sólo representa el buzón ASCII tradicional. Para una parte local con caracteres no ASCII, RFC 9598 define SmtpUTF8Mailbox dentro de otherName. Su OID es 1.3.6.1.5.5.7.8.9 y aparece en el registro SMI de IANA. La carga es una UTF8String no vacía.

La elección no pregunta si toda la dirección “parece internacional”. Pregunta si la parte local contiene no ASCII. Si lo contiene, se usa SmtpUTF8Mailbox. Si no, se usa rfc822Name, incluso con un dominio internacionalizado. Por eso los dos tipos nunca deben coincidir entre sí.

El valor no es una cabecera de presentación. No incluye nombre personal, comentario ni corchetes angulares. Tampoco admite marca de orden de bytes. RFC 3629 define UTF-8 y RFC 6532 aporta el contexto de las cabeceras internacionalizadas, pero ninguno convierte la presentación en identidad certificada.

Guardar únicamente el texto extraído destruye evidencia. Un recibo útil conserva DER, etiqueta GeneralName, OID, tipo ASN.1 y octetos. Así puede distinguirse un certificado mal emitido de un parser que leyó mal o de una aplicación que aplicó una transformación no autorizada.

IDNA autoriza preparar sólo el dominio

Todos los dominios de correo presentes en certificados deben cumplir IDNA2008 sin mappings implícitos. RFC 5890 define U-label, A-label y LDH. RFC 5891 define la conversión de protocolo.

Dentro del certificado, cualquier etiqueta no ASCII se almacena como A-label. Las etiquetas ASCII ordinarias siguen NR-LDH. Las letras de A-label y NR-LDH se guardan en minúsculas. El certificado tiene así una única forma de comparación.

Cuando la dirección candidata procede de un mensaje o de entrada humana, primero se quitan frase, comentario y ángulos. Después se convierten los U-labels del dominio en A-labels y se pasan a minúsculas las letras pertinentes del dominio. Esa preparación puede hacer que dos representaciones de dominio converjan legítimamente.

El cambio respecto de RFC 8398 es importante. La norma anterior aceptaba condicionalmente U-labels o A-labels. RFC 9598 exige A-labels siempre en el certificado para reducir complejidad en la validación del camino. Sin embargo, publicar la nueva regla no prueba que una CA haya migrado, que un validador la aplique o que una flota haya reemplazado certificados antiguos.

La parte local permanece como fue emitida

El correo internacional parte del marco de RFC 6530 y de la extensión SMTP de RFC 6531. Esos documentos permiten UTF-8 en la parte local, pero no definen una normalización universal para decidir que dos buzones son el mismo.

RFC 9598 ordena no transformar la parte local al preparar una comparación. No hay cambio de mayúsculas. No hay normalización Unicode. No hay equivalencia de compatibilidad. Una vez preparado el dominio, la dirección se compara octeto por octeto. Dos valores SmtpUTF8Mailbox certificados también se comparan directamente por sus octetos.

El motivo es de seguridad y de atribución. Unicode permite caracteres visualmente semejantes y distintas secuencias para texto percibido como igual. Si el sistema de correo aprovisionó una secuencia y la CA certificó otra, normalizarlas en el último momento oculta la contradicción y asigna al comparador una autoridad que nadie registró.

El rechazo también tiene coste. Una persona puede ver dos nombres idénticos y no entender por qué fallan. Ese problema debe resolverse en emisión o aprovisionamiento, preservando las dos pruebas. Aceptar mediante una transformación silenciosa parece más amable, pero crea una identidad cuyo origen ya no puede explicarse.

Las restricciones de nombre abarcan ambas formas

Los dos tipos representan un único espacio de direcciones. Una CA subordinada limitada a un dominio no debe escapar de ese límite por usar otherName. RFC 9549 actualiza las reglas de RFC 5280 para que restricciones rfc822Name cubran también SmtpUTF8Mailbox.

La restricción de CA se expresa como rfc822Name con dominio conforme a IDNA2008 y A-label. Para comprobarla, se prepara el dominio del sujeto, se elimina la parte local y se compara el host completo o el sufijo. No se recomiendan restricciones dedicadas a un buzón particular.

Este éxito no certifica existencia. Sólo muestra que la CA podía emitir dentro de ese dominio bajo el camino construido. Aún hacen falta firma y camino válidos, ancla correcta, estado de revocación, propósito del certificado y política de la parte que confía. Y si importa el control actual del buzón, hace falta una prueba actual.

Un único indicador “X.509 OK” no permite saber si se analizó el OID, se compararon los bytes, se aplicaron restricciones o simplemente se encontró una firma válida. La trazabilidad debe conservar cada decisión.

El certificado no transporta el mensaje

La separación con SMTPUTF8 es esencial. RFC 6531 permite negociar una ruta que conserve direcciones internacionales. Una coincidencia RFC 9598 no obliga al siguiente relay a soportarla. Una ruta SMTPUTF8 correcta tampoco demuestra que un certificado identifique al remitente o destinatario.

Tampoco hay salto automático hacia autorización. El certificado puede nombrar el buzón exacto y aun así estar fuera de propósito, revocado o encadenado a un ancla no admitida. La aplicación puede reconocer al principal y denegar la operación. El servidor puede aceptar el mensaje y la entrega final puede fallar. Cada verbo necesita su evidencia.

La primacía del código en ejecución de Lu Heng exige observar bytes y decisiones reales, no una etiqueta de conformidad. Su especificación inicial mínima ayuda a ver el límite: la norma comparte representación y comparación, mientras emisión, aprovisionamiento y autorización siguen siendo locales. Las capas de realidad evitan que una coincidencia simbólica hable por el control, el transporte o el resultado.

Fuentes