Résumé

  • Le RFC 10031 définit id-on-MACAddress, une forme otherName de six ou huit octets pour EUI-48 et EUI-64, ainsi que des contraintes masquées applicables au chemin de certification.
  • Le certificat atteste une association établie par une autorité de certification selon sa méthode de validation. Il ne transforme ni une adresse usurpable et parfois changeante, ni son préfixe, en identité complète de l’équipement ou en droit d’action.

La durée du certificat et celle de la pièce

Dans le certificat, la valeur est volontairement austère. Six octets représentent EUI-48, huit représentent EUI-64. L’ordre est celui de l’octet le plus significatif vers le moins significatif. Les tirets, deux-points et points appartiennent aux écrans d’administration. Le contrôle par la partie utilisatrice est une comparaison octet par octet, sans joker.

Cette exactitude exclut les raccourcis. La valeur ne désigne pas « tout matériel du même constructeur », « n’importe quel port du châssis » ou « l’adresse active aujourd’hui ». Elle désigne une adresse déterminée, portée dans le SAN ou éventuellement l’IAN sous l’OID 1.3.6.1.5.5.7.8.12.

Le RFC impose à l’autorité de certification de vérifier que l’adresse appartient, ou devrait appartenir, à l’appareil sujet pendant toute la durée du certificat. Deux appareils distincts ne doivent pas recevoir des certificats contenant la même adresse, sauf s’ils partagent effectivement la même interface de couche 2.

La règle est forte, mais elle déplace une question vers l’exploitation: qu’est-ce qui se passe lorsque la pièce part avant le certificat ? Un échange de carte, une réparation, une réaffectation ou une désactivation peuvent laisser une chaîne cryptographique valide avec un nom devenu historiquement exact. Le RFC ne peut pas connaître l’inventaire. C’est au système local de relier remplacement, révocation et réémission.

Une adresse observée n’est pas une possession de clé

La partie sécurité du texte rappelle que la liaison vaut ce que vaut la validation de la CA. Celle-ci doit tenir compte de l’usurpation des adresses MAC. Les adresses dynamiques ou partagées réduisent l’unicité et la responsabilité. En dehors du réseau local, aucune unicité ne doit être présumée sans preuve de stabilité entre les domaines.

Deux mesures différentes sont donc nécessaires. La validation du chemin et une preuve de clé indiquent que le correspondant détient la clé privée associée au certificat. L’observation du lien indique quelle adresse source a été utilisée sur un port ou lors d’une association radio. Une adresse correcte sans clé peut être usurpée; une clé correcte peut être présentée alors que l’interface nommée n’est plus celle qui transporte le trafic.

Le certificat auto-signé n’abolit pas ce problème. Le RFC exige alors l’adresse d’un port physique, mais l’auto-signature ne fournit pas le motif externe de confiance. Elle ne crée ni inventaire, ni posture, ni autorisation.

La confidentialité produit volontairement de l’instabilité

Apple explique que ses appareils utilisent une adresse Wi-Fi privée différente selon le réseau et peuvent choisir des modes fixe ou rotatif. Android active par défaut la randomisation en mode client depuis Android 10 et documente des valeurs locales unicast généralement persistantes par SSID. Ce ne sont pas des anomalies que le certificat devrait corriger. Ce sont des protections contre la corrélation des activités et des déplacements.

Le RFC 10031 reconnaît lui-même ce coût. Une adresse immuable placée dans un certificat facilite le suivi durable de l’appareil et, indirectement, de son utilisateur. Il invite à envisager la rotation, des certificats courts ou la randomisation lorsque c’est possible.

Le choix de nommer l’adresse matérielle peut préserver un repère de fabrication, mais il ne correspondra pas toujours à l’adresse visible. Le choix de certifier une adresse privée peut mieux suivre le lien courant, mais dépend d’un réseau, d’un état logiciel ou d’une période de rotation. La politique doit annoncer ce que le nom représente et l’événement qui met fin à sa validité opérationnelle.

Le masque subordonne une CA, pas un appareil

Pour les Name Constraints, la valeur double de taille. Une première moitié décrit le motif, la seconde les bits significatifs. Une contrainte EUI-48 occupe douze octets; une contrainte EUI-64, seize. Les sous-arbres permis s’intersectent dans le chemin, tandis que les sous-arbres exclus s’unissent.

Le mécanisme peut limiter une CA subordonnée à une plage ressemblant à un OUI, ou aux adresses universelles unicast. C’est une vraie limitation du pouvoir d’émission. Ce n’est pas une autorisation d’application. Un chemin acceptable ne dit pas que l’appareil peut entrer dans un réseau de production, actionner un équipement ou signer une version logicielle.

Même l’OUI est une preuve circonscrite. Le RFC avertit que les bits universal/unicast ne prouvent pas qu’un préfixe de 24 bits soit enregistré. Les documents IEEE distinguent OUI, CID, EUI globalement destiné à être unique et identifiant local dont l’administrateur garantit seulement l’unicité dans son domaine. Le préfixe renseigne sur une allocation; il n’établit pas le propriétaire actuel, le fabricant présent, la chaîne de garde ou le rôle métier.

Conserver chaque décision à sa place

Un système robuste garde séparément le chemin de certificat, sa politique et son état de révocation; la preuve de possession de clé; l’adresse du SAN; les contraintes appliquées; l’adresse réellement observée; le port ou l’association; l’objet d’inventaire; la posture; le rôle; et la décision demandée.

Ces éléments n’ont pas la même horloge. Le certificat expire, l’adresse privée tourne, la carte est remplacée, l’actif change d’équipe, la posture vieillit et la politique d’accès évolue. Le désaccord entre eux est un signal à examiner, pas une erreur à cacher sous un identifiant maître.

Le mérite du RFC 10031 est d’apporter la plus petite règle commune qui manquait. Il rend interopérable un nom d’interface et ses contraintes, sans imposer un passeport universel de l’appareil. L’adoption peut rester volontaire et localisée. Le code en fonctionnement doit montrer que l’usage résiste à la maintenance, aux interfaces multiples, à la randomisation et au retour arrière avant que l’organisation élargisse son mandat.

Sources