Résumé

  • RFC 9598 réserve SmtpUTF8Mailbox aux adresses dont la partie locale contient du non-ASCII ; une partie locale entièrement ASCII reste un rfc822Name, même avec un domaine internationalisé.
  • Le domaine est converti en A-label IDNA2008 et en minuscules. La partie locale UTF-8 ne subit ni casse, ni normalisation, ni substitution : l’égalité finale se décide octet par octet.
  • Cette égalité ne prouve ni le contrôle actuel de la boîte, ni l’usage autorisé du certificat, ni la capacité SMTPUTF8 du trajet, ni la remise du message. Chacun de ces résultats exige son propre reçu.

Le problème commence souvent bien avant la validation. Une équipe de messagerie ouvre une boîte à partir d’un formulaire Unicode. Une autre équipe demande un certificat. Les deux interfaces affichent le même nom. Quelques mois plus tard, un service compare l’adresse fournie par l’utilisateur au subjectAltName du certificat. L’écran dit « identique ». Les octets disent le contraire.

RFC 9598 choisit les octets. Ce choix peut sembler sévère, mais il évite que la bibliothèque Unicode du dernier composant devienne, sans mandat, l’autorité qui décide quelles boîtes constituent une même identité.

Le type de nom consigne déjà une décision

La notice RFC Editor et le Datatracker de l’IETF datent la norme proposée de mai 2024. Elle met à jour RFC 5280 et remplace RFC 8398.

Dans le profil PKIX historique, rfc822Name représente une adresse dont la partie locale est ASCII. Pour porter une partie locale internationale, RFC 9598 emploie l’extension otherName de GeneralName. Le type SmtpUTF8Mailbox utilise l’OID 1.3.6.1.5.5.7.8.9, publié dans le registre SMI de l’IANA, et sa valeur est une UTF8String ASN.1 non vide.

La bifurcation ne dépend pas de l’apparence générale de l’adresse. Elle dépend de la partie locale. Dès que celle-ci contient un caractère non-ASCII, SmtpUTF8Mailbox est obligatoire. Si elle reste ASCII, rfc822Name demeure obligatoire, même si le domaine visible contient des caractères internationaux.

Un inventaire de certificats doit donc conserver le tag GeneralName, l’OID et la valeur brute. Extraire seulement une chaîne « email » commune aux deux formes supprime une preuve utile. Un générateur qui choisit le mauvais type ne produit pas une variante esthétique ; il sort du contrat de compatibilité, notamment vis-à-vis des contraintes de nom.

La valeur certifiée n’est pas une adresse d’affichage. Elle n’inclut ni nom de personne, ni commentaire, ni chevrons. Elle ne doit pas contenir de marque d’ordre des octets. La définition de l’UTF-8 vient de RFC 3629, tandis que RFC 6532 borne l’emploi de l’UTF-8 dans les en-têtes de courrier internationalisés.

Le domaine possède une procédure de mise en forme

Les domaines de toutes les adresses de courrier présentes dans un certificat doivent respecter IDNA2008 sans appliquer des correspondances implicites. RFC 5890 définit notamment U-label, A-label et LDH. RFC 5891 décrit les conversions de protocole.

Dans le certificat, un label international doit être stocké sous forme A-label, jamais U-label. Les labels ASCII ordinaires respectent NR-LDH. Les lettres de tous les labels du domaine sont en minuscules. RFC 9598 impose ainsi une forme de comparaison unique à l’intérieur de l’objet signé.

L’adresse externe demande une préparation limitée. On retire la syntaxe d’affichage, on convertit les U-labels du domaine en A-labels et on met les lettres admissibles du domaine en minuscules. Cette opération a une autorité précise : le protocole IDNA définit comment représenter le nom de domaine pour cette comparaison.

RFC 8398 admettait encore, selon les cas, A-labels ou U-labels. RFC 9598 supprime cette alternative. Ce changement réduit les conversions dans le validateur de chemin, mais il ne démontre ni que les autorités de certification ont réémis leurs certificats, ni que les bibliothèques ont adopté la nouvelle règle, ni que les applications enregistrent la forme effectivement comparée.

La partie locale n’a pas de normalisation universelle

La partie locale internationale s’appuie sur le cadre de RFC 6530 et l’extension SMTP de RFC 6531. Elle est codée en UTF-8. Cela ne signifie pas que deux suites Unicode proches, ni même deux rendus identiques, désignent la même boîte.

RFC 9598 interdit toute transformation de cette partie locale avant comparaison. Pas de conversion de casse. Pas de normalisation Unicode. Pas de remplacement de compatibilité. Une fois le domaine préparé, la boîte entière se compare octet par octet. Deux valeurs SmtpUTF8Mailbox déjà présentes dans des certificats ne demandent aucune préparation supplémentaire. Une valeur SmtpUTF8Mailbox et un rfc822Name ne correspondent jamais, puisque leurs conditions sur la partie locale sont mutuellement exclusives.

Cette règle rend visible une divergence que beaucoup de systèmes préfèrent cacher. Le serveur de courrier peut avoir créé une boîte avec une représentation Unicode ; l’autorité de certification peut en avoir reçu une autre ; l’annuaire peut en stocker une troisième. Si l’on normalise au moment du contrôle, on transforme le validateur en arbitre rétroactif de leur équivalence.

L’échec binaire peut provoquer un incident d’interopérabilité pour deux chaînes visuellement semblables. C’est précisément le signal à préserver. Il indique que l’émission et la configuration ne partagent pas la même identité technique. Une équipe peut alors corriger la boîte ou réémettre le certificat. Un succès obtenu par transformation silencieuse ne laisse plus savoir quelle autorité s’est trompée.

Les contraintes de nom ferment une voie de contournement

rfc822Name et SmtpUTF8Mailbox représentent le même espace logique d’adresses. Une autorité intermédiaire pouvait déjà être limitée à un domaine par une contrainte rfc822Name. Sans règle complémentaire, la nouvelle forme otherName risquerait de contourner cette délégation.

RFC 9549 adapte les règles PKIX pour que la contrainte couvre les deux formes. Une autorité qui limite les adresses électroniques utilise une contrainte rfc822Name conforme à IDNA2008, avec le domaine international sous forme A-label. Le validateur prépare le domaine du sujet, retire la partie locale, puis compare exactement l’hôte ou le suffixe de domaine. Les contraintes visant une boîte particulière sont déconseillées.

Le résultat prouve seulement que l’adresse certifiée se trouve dans l’espace de noms que cette autorité pouvait émettre. Il ne crée pas la boîte. Il ne démontre pas que le sujet en a encore le contrôle. Il ne donne pas au certificat un usage que la politique de l’application refuse.

Le reçu complet doit donc séparer le décodage du nom, la comparaison de la boîte, la contrainte de domaine, le chemin de certification, l’usage de clé, la politique de confiance et la décision applicative. Conserver un unique booléen « certificat valide » rend impossible de savoir laquelle de ces opérations a réellement eu lieu.

Un nom égal n’ouvre pas la route du courrier

Le transport appartient à un autre mécanisme. RFC 6531 permet à des serveurs SMTP d’annoncer et d’accepter des enveloppes internationales. Un certificat peut contenir la bonne boîte alors qu’un relais du trajet ne sait pas la transporter. À l’inverse, un message peut parcourir un chemin SMTPUTF8 sans qu’aucun certificat RFC 9598 soit présenté.

La validité du chemin X.509 reste elle aussi plus étroite que l’autorisation. Il faut connaître l’ancre de confiance, les contraintes, l’état de révocation, le but admis pour la clé et la liaison attendue par l’application. Puis il faut une preuve actuelle du contrôle de la boîte si cette propriété compte. Enfin, l’action et son effet doivent être observés.

La primauté du code en fonctionnement de Lu Heng remplace la formule « compatible RFC 9598 » par une trace reproductible : octets DER, type de nom, domaine avant et après IDNA, partie locale intacte, résultat de comparaison, chemin, contrainte, politique, action et effet.

Sa spécification initiale minimale éclaire la portée volontairement réduite de la norme : une représentation et un algorithme communs, sans centraliser la création des boîtes, la pratique des autorités ou les permissions locales. Les couches de réalité empêchent enfin le nom signé de parler à la place du service de courrier, du validateur ou de l’utilisateur.

Sources