Résumé

  • La RFC 10031 définit un otherName X.509 contenant exactement six octets pour une EUI-48 ou huit pour une EUI-64. La comparaison du nom est intégrale, octet par octet, sans caractère générique.
  • Une chaîne valide et une valeur identique attestent un résultat cryptographique borné. Elles n’observent ni le port utilisé maintenant, ni l’origine d’une trame, ni l’intégrité de l’équipement, ni l’autorisation accordée par le réseau local.
  • Une décision robuste conserve séparément l’allocation IEEE ou locale, la preuve acceptée par l’AC, la validation du chemin, l’observation de couche 2, la règle d’accès et la durée de corrélation de l’identifiant.

Une adresse MAC semble offrir ce que les systèmes d’identité recherchent : une petite valeur stable, proche de la machine et facile à comparer. Le certificat ajoute une clé publique et une signature. Réunis, les deux objets donnent vite l’impression d’une identité matérielle achevée.

La RFC 10031 apporte quelque chose de plus modeste et, pour cette raison, plus utile. Publiée sur la voie des normes de l’IETF en août 2026, Media Access Control (MAC) Addresses in X.509 Certificates a cinq auteurs : Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo et Michael StJohns. Elle crée le nom id-on-MACAddress dans GeneralName.otherName. Une adresse IEEE 802 de 48 bits y occupe exactement six octets ; une EUI-64, huit. Les deux-points ou tirets de l’affichage humain n’entrent pas dans le certificat.

Le contrôle d’égalité est strict. La partie qui s’y fie compare les octets reçus à ceux du certificat ; aucun joker ne permet de remplacer un fragment. Cette définition écarte les désaccords de casse, de séparateur ou de zéro initial et fournit un nom commun à des mécanismes d’authentification de couche 2 ou de provisionnement sécurisé, notamment envisageables pour l’IoT et l’automobile.

Mais la propreté du format ne crée pas l’unicité du monde physique. Le certificat rapporte une affirmation formée lors de son émission. Il n’est pas présent sur le port pour constater quelle interface émet aujourd’hui. Il ne détecte pas à lui seul le clonage, la réaffectation, le partage ou l’usurpation de l’adresse.

Le parcours de Housley aide à situer cette précision sans personnaliser la norme. Sa fiche IETF, conservée le 31 août 2026, recense 127 RFC, dont la RFC 10031. La biographie y indique un travail en sécurité informatique et réseau depuis 1982, la création de Vigil Security en 2002, la présidence de l’IETF de 2007 à 2013 et celle de l’IAB de 2013 à 2015. Le tableau daté mentionne aussi la présidence de LAMPS et la fonction de liaison avec IEEE-SA. Ces repères n’en font ni l’auteur unique, ni le responsable d’une AC ou d’un réseau particulier.

Le préfixe ne raconte pas toute l’allocation

Avant l’émission, il faut répondre à une question que X.509 ne tranche pas : pourquoi le demandeur peut-il employer cette valeur ?

L’IEEE Registration Authority tient les registres et délivre des identifiants suivant les normes IEEE. Elle distingue les produits MA-L, MA-M et MA-S du CID. Un CID ne donne pas le droit de produire des EUI-48 ou EUI-64. La RFC 9542 sépare elle aussi l’espace EUI-48 attribué mondialement des adresses administrées localement et renvoie aux sources IEEE pour les affectations officielles.

Cette distinction interdit de lire l’autorité dans quelques octets familiers. Lorsqu’une adresse est locale, le détenteur d’un OUI ne reçoit aucun privilège particulier parce que le début de la valeur ressemble à cet OUI. La RFC 9542 précise en outre qu’il n’existe pas de méthode automatique pour savoir si un réseau local applique le Structured Local Address Plan.

Il faut donc garder la chaîne d’allocation : type d’adresse, registre ou responsable local, bloc ou règle utilisé, allocation subordonnée, interface concernée et date de la preuve. Un motif binaire peut classer une valeur ; il ne remplace pas la décision de celui qui l’a attribuée.

L’agence est distribuée. IEEE maîtrise son registre. Un constructeur ou un exploitant gère les valeurs sous son contrôle. L’autorité de certification évalue une demande. Le réseau destinataire choisit ce qu’il permet. Le mandat de l’un n’est pas transmis par voisinage au suivant.

Ce que l’autorité de certification a réellement vérifié

La RFC 10031 impose à l’AC de s’assurer que l’adresse incluse appartient, ou devrait appartenir, à l’équipement sujet pendant la durée du certificat. Elle demande de ne pas placer la même valeur dans des certificats de dispositifs différents, sauf s’ils partagent la même interface de couche 2. Pour un certificat auto-signé, l’adresse doit correspondre à un port physique.

Ces obligations rendent la phase d’enrôlement centrale. Encore faut-il savoir comment elles ont été satisfaites. Une base de fabrication, un inventaire authentifié, une possession de clé dans le matériel ou une procédure physique n’ont pas la même résistance. La RFC elle-même rappelle que la liaison vaut ce que vaut la validation de l’AC et qu’il faut tenir compte de l’usurpation.

Le reçu d’émission devrait identifier le souscripteur, le dispositif, l’interface revendiquée, les six ou huit octets exacts, la méthode et l’heure de preuve, l’émetteur, le numéro de série, la période de validité et l’état de révocation. Sans ce contexte, « l’adresse figure dans le certificat » décrit une structure, pas la qualité de la preuve.

Le temps modifie ensuite les faits. Un port peut être remplacé, une interface virtuelle recréée, une adresse partagée ou réaffectée. Un certificat encore valide peut continuer à refléter une justification devenue fausse. La révocation aide seulement si l’écart est connu, signalé puis vérifié par le système qui décide.

Les Name Constraints bornent un espace de noms

Pour le nouveau otherName, la RFC 10031 définit aussi des Name Constraints. Elles associent un motif de valeur et un masque : douze octets pour EUI-48, seize pour EUI-64. Le premier élément a la taille de l’adresse et le second indique les bits pertinents pour l’espace permis ou exclu.

Ce mécanisme ne transforme pas le nom présenté en joker. La valeur du certificat demeure entière et sa comparaison exacte. C’est le certificat d’AC qui peut limiter le sous-espace dans lequel les certificats suivants doivent placer leurs noms.

La RFC 5280 est décisive pour ne pas élargir cette conclusion. Les Name Constraints sont portées par les certificats d’AC et agissent sur les noms des certificats ultérieurs du chemin. Elles ne concernent le subjectAltName que si la forme de nom est présente et ne s’appliquent généralement pas aux certificats auto-émis, sauf au dernier certificat du chemin.

Un contrôle réussi dit donc : sous cet ancrage, cette politique et ces contraintes, le nom appartient à l’espace de certificats autorisé. Il ne dit pas que l’IEEE a attribué la valeur au sujet, que le port l’utilise maintenant ou que le réseau accepte l’opération. Le masque organise une délégation de nom ; il ne supprime pas les collisions ou les réemplois hors de ce contexte.

Conserver le résultat exige l’ancrage de confiance, la chaîne, la politique, l’heure, la valeur SAN, les contraintes permises et exclues et les informations de révocation. C’est un reçu de chemin, pas un relevé de commutateur.

La couche 2 a sa propre horloge

Une adresse MAC est normalement significative dans un périmètre local. La RFC 10031 déconseille d’en supposer l’unicité au-delà, puisque ces valeurs ne sont pas habituellement routées à travers les frontières de couche 3. Deux réseaux isolés peuvent utiliser légitimement la même adresse locale. Le même réseau peut aussi rencontrer un doublon accidentel ou hostile.

Le système qui agit doit joindre le certificat à l’événement observé : protocole et résultat d’authentification, preuve de possession de clé, adresse source, interface physique ou logique, point d’attachement, VLAN, état d’attribution ou de randomisation, recherche de doublon et horodatage.

Une égalité d’octets devient alors une pièce bien délimitée. Elle prouve que la valeur présentée est la valeur certifiée. Elle ne prouve pas que toutes les trames suivantes viennent du même matériel, que le logiciel du dispositif est sain ou que l’utilisateur est celui que l’organisation imagine.

La priorité au code en fonctionnement ne dévalue pas le standard. Elle place chaque preuve à son niveau. La norme fournit la syntaxe partagée ; la PKI produit un résultat cryptographique ; le réseau en service produit l’observation et le résultat opérationnel.

L’admission est une décision, pas une propriété du certificat

Un équipement correctement authentifié peut devoir rester en quarantaine. Il peut se trouver sur un port inattendu, demander une action excessive, dépasser une fenêtre de maintenance ou ne pas satisfaire un profil local. Inversement, une intervention manuelle peut autoriser temporairement un écart documenté.

Le reçu d’autorisation doit nommer la règle, son propriétaire, les attributs évalués, l’action accordée, le périmètre, l’expiration, l’exception et le résultat. Si la validation du chemin réussit mais que l’accès est refusé, les deux événements sont vrais. Les fusionner en « certificat invalide » détruit l’explication.

Cette séparation protège la responsabilité. Les auteurs de la RFC spécifient une primitive interopérable ; l’AC émet ; l’exploitant observe et applique sa politique ; l’application qui se fie à la preuve transforme les données en conséquence. Aucun certificat ne permet à l’émetteur de prendre silencieusement la place de l’administrateur local.

La stabilité est aussi une capacité de suivi

La même persistance qui facilite l’administration facilite la corrélation. La RFC 10031 avertit qu’une adresse stable placée dans un certificat peut servir à suivre durablement un appareil ou son utilisateur. Elle invite à envisager la rotation, des certificats courts ou la randomisation lorsque cela est possible.

La RFC 6973 décrit la corrélation comme la réunion d’informations relatives à une personne et le fingerprinting comme l’identification d’un appareil ou d’une instance au moyen de plusieurs éléments. Un identifiant persistant à n’importe quelle couche, certificat compris, peut relier des communications éloignées dans le temps.

Il ne suffit donc pas de dire que le canal est chiffré. Le certificat peut être visible ou journalisé, et les traces d’authentification peuvent être rapprochées d’autres champs. Il ne suffit pas non plus d’ordonner une randomisation universelle : certains environnements ont besoin de stabilité, et une rotation mal coordonnée peut casser l’admission.

La décision de confidentialité doit préciser les observateurs, le périmètre, la durée de l’adresse et du certificat, les autres données joignables, la faisabilité d’une rotation et la suppression des journaux. La cryptographie protège certaines propriétés ; elle ne rend pas l’identifiant neutre.

Six preuves au lieu d’une confiance globale

Une architecture démontrable conserve six objets : le fondement IEEE ou local de l’allocation ; la validation de l’AC ; le résultat du chemin X.509 ; l’interface et l’adresse réellement observées ; la règle d’autorisation ; enfin, la persistance et la fin de vie des données.

Chacun peut réussir tandis que le suivant échoue. Une valeur correctement attribuée peut être mal enrôlée. Un certificat bien émis peut être révoqué. Une chaîne valide peut accompagner une source usurpée. Un appareil authentique peut ne pas avoir le droit demandé. Une admission légitime peut conserver trop longtemps un identifiant corrélable.

La RFC 10031 donne un nom précis autour duquel joindre ces preuves. Elle ne promet pas que ce nom les remplace.

Sources