Résumé

  • La version du 30 septembre 2026 du projet « TLS Trust Anchor Identifiers » ramène de 255 à 32 octets la longueur maximale de la représentation binaire d’un identifiant. La structure TLS TrustAnchorID passe elle aussi à une plage de 1 à 32 octets. Il s’agit encore d’un Internet-Draft du groupe de travail, classé I-D Exists par l’IESG, et non d’une RFC publiée.
  • Un nouveau chapitre demande de traiter correctement les composantes OID arbitrairement grandes : ni débordement d’entier, ni confusion entre un identifiant valide et une limite d’affichage locale. La sélection d’une chaîne reste distincte de la décision, prise par la partie qui vérifie, de faire confiance à une autorité de certification.

Qui peut dire qu’une autorité de certification est acceptable ? Certainement pas le seul identifiant inscrit dans un échange TLS. Ce signe peut orienter la partie qui s’authentifie vers une chaîne de certificats compatible avec les autorités connues de son interlocuteur. Mais c’est ce dernier qui entretient la liste des ancres auxquelles il fait confiance et qui valide finalement le chemin. Le projet du groupe TLS cherche à mieux faire fonctionner cette négociation, particulièrement quand les différents clients n’ont pas mis à jour leurs magasins de confiance au même rythme.

La différence entre les versions 05 et 06 est vérifiable dans les textes hébergés par l’IETF. Le 14 septembre, la représentation binaire d’un identifiant pouvait atteindre 255 octets ; le texte daté du 30 septembre fixe la limite à 32. La définition de TrustAnchorID suit le même mouvement, de <1..2^8-1> vers <1..32>. Les auteurs expliquent que ce choix maintient les formes binaires et décimales pointées, relatives ou complètes, confortablement sous 255 octets. Ce plafond porte sur la taille d’un identifiant individuel. Il n’impose pas un maximum de 32 autorités de certification dans un magasin de confiance.

Pourquoi employer un tel identifiant ? Le mécanisme trust_anchors permet à une partie authentifiante disposant de plusieurs chemins de choisir un certificat que la partie vérificatrice est susceptible de reconnaître. Il peut éviter d’énumérer de longs noms X.509 dans l’extension certificate_authorities. Pour un ancrage individuel, l’exploitant de l’autorité de certification attribuerait normalement l’identifiant. Pour un groupe d’ancres, l’utilité dépend d’un accord sur sa signification entre les acteurs concernés. Dans les deux cas, la présence du nom ne remplace ni la configuration locale des ancres ni les contrôles cryptographiques de la chaîne.

La nouvelle version traite aussi d’un risque de représentation moins visible. Une composante d’OID peut être un entier arbitrairement grand, même si l’identifiant binaire complet est limité à 32 octets ; les motifs de correspondance de groupes connaissent la même difficulté. Un logiciel qui interprète tout avec un entier de taille fixe peut dépasser sa capacité ou comparer une autre valeur que celle reçue. Le projet interdit les comportements indéfinis et recommande de conserver les octets pour comparer les identifiants et exécuter les règles de correspondance.

Ce conseil n’est pas un jugement sur les produits existants ; le texte ne donne pas d’inventaire de leurs implémentations.

Un administrateur peut pourtant avoir besoin d’une notation décimale pointée dans un fichier ou un outil de diagnostic. Le projet autorise une limite propre à ce contexte, à condition de traiter de façon interopérable les identifiants valides mais non pris en charge localement. L’implémentation TLS doit pouvoir recevoir des composantes OID de taille arbitraire dans les messages spécifiés. Elle peut écarter un identifiant non pris en charge avant de le transmettre à un autre composant ; si tous ceux d’EncryptedExtensions sont écartés, l’effet est celui d’une extension absente. Les implémentations qui limitent les composantes devraient couvrir au moins la plage jusqu’à 2^32-1, correspondant à l’étendue des numéros d’entreprise privés, et les allocations devraient rester dans cette plage. « Devraient » n’est pas une obligation universelle « doivent ».

Une autre correction remplace dans l’exemple d’un groupe versionné le maximum 2^64-1 par l’infini. Elle ne signifie pas qu’un registre de racines en service a été modifié. Le statut officiel reste celui d’un projet de groupe de travail, sans approbation IESG ni déploiement attesté. La nouveauté démontrée est plus précise : une borne sur les octets transmis et un traitement explicite des valeurs que certains logiciels locaux pourraient ne pas savoir afficher.

Sources