Zusammenfassung

  • RFC 10031 führt id-on-MACAddress als X.509-otherName ein: genau sechs Oktette für EUI-48 oder acht für EUI-64. Der Vergleich erfolgt vollständig Byte für Byte; Platzhalter sind ausgeschlossen.
  • Ein gültiger Pfad und passende Name Constraints belegen eine begrenzte PKI-Aussage. Sie beobachten weder den aktuellen Port noch die Herkunft eines Frames, die Integrität des Geräts, die Person am Gerät oder die lokale Berechtigung.
  • Belastbare Entscheidungen halten IEEE- beziehungsweise lokale Zuweisung, CA-Prüfung, Pfadvalidierung, Layer-2-Beobachtung, Autorisierung und Datenschutz-Lebensdauer als getrennte Nachweise fest.

Eine MAC-Adresse wirkt wie ein fertiger Anker für Geräteidentität. Sie ist kompakt, an eine Netzwerkschnittstelle angelehnt und leicht zu vergleichen. Bindet ein Zertifikat dieselbe Zeichenfolge an einen öffentlichen Schlüssel, scheint die Identitätsfrage erledigt.

RFC 10031 löst jedoch eine kleinere, präzisere Aufgabe. Media Access Control (MAC) Addresses in X.509 Certificates erschien im August 2026 als IETF-Standard. Die Autoren sind Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo und Michael StJohns. Das Dokument definiert id-on-MACAddress innerhalb von GeneralName.otherName. Eine 48-Bit-Adresse nach IEEE 802 wird als exakt sechs Oktette codiert, eine EUI-64 als acht. Doppelpunkte, Bindestriche oder Punkte der menschlichen Schreibweise werden nicht übernommen.

Die vertrauende Seite prüft vollständige Byte-Gleichheit. Wildcards gibt es nicht. Damit verschwinden Formatfragen zu Großschreibung, Trennzeichen und führenden Nullen. Zertifikatsbasierte Authentisierung auf Layer 2 und sicheres Provisioning, etwa in IoT- oder Fahrzeugnetzen, erhalten eine interoperable Namensform.

Das ist eine technische Möglichkeit, keine Einführungsstatistik. Die RFC belegt weder die Umsetzung durch einen benannten Hersteller noch durch eine CA, ein Fahrzeug oder ein Produktionsnetz. Vor allem macht die genaue Codierung das Zertifikat nicht zum Sensor.

Housleys Profil ordnet die Arbeit ein. Der am 31. August 2026 erfasste IETF-Datatracker nennt 127 RFCs einschließlich RFC 10031. Seine Biografie verzeichnet Sicherheitsarbeit seit 1982, die Gründung von Vigil Security 2002, den Vorsitz der IETF von 2007 bis 2013 und den Vorsitz des IAB von 2013 bis 2015. Am selben Stichtag führte die Rollentabelle ihn als Chair von LAMPS und Liaison Manager zu IEEE-SA. Das beschreibt langjährige Mitarbeit; es macht ihn nicht zum alleinigen Erfinder oder Betreiber einer CA, eines Registers oder Netzes.

Zuweisung kommt vor Ausstellung

Bevor eine CA die Adresse in ein Zertifikat schreibt, braucht der Antragsteller eine tragfähige Grundlage für ihre Nutzung. Global zugewiesener und lokal verwalteter Adressraum liefern dabei unterschiedliche Belege.

Die IEEE Registration Authority führt und vergibt Kennungen nach IEEE-Standards. MA-L, MA-M und MA-S sind von CID zu unterscheiden; aus einem CID dürfen keine EUI-48- oder EUI-64-Werte erzeugt werden. RFC 9542 trennt ebenfalls global zugewiesenen EUI-48-Raum von lokal verwalteten Adressen und verweist für verbindliche Registrierungsdaten auf IEEE-Quellen.

Die ersten Oktette allein beweisen daher weder Hersteller noch gegenwärtigen Besitzer. Bei lokal verwalteten Werten hat der Inhaber einer ähnlich aussehenden OUI keine besondere Befugnis. RFC 9542 stellt zudem fest, dass nicht automatisiert ermittelt werden kann, ob ein lokales Netz den Structured Local Address Plan einhält.

Ein Zuweisungsbeleg sollte Adressklasse, Zuweiser, Block oder lokale Regel, untergeordneten Wert, vorgesehene Schnittstelle, Geltungsbereich und Datum nennen. Bei lokaler Vergabe gehören Plan und Kollisionskontrolle dazu. Das Bitmuster klassifiziert den Wert, rekonstruiert aber keine Verwaltungsentscheidung.

Hier sind Zuständigkeiten geteilt. IEEE verwaltet seine Register. Hersteller, Eigentümer oder Netzbetreiber vergeben innerhalb ihres Bereichs. Die CA prüft den Anspruch. Das Zielnetz entscheidet über die Konsequenz. Die Signatur eines Akteurs übernimmt nicht die Mandate der anderen.

Das Zertifikat konserviert eine Prüfentscheidung

RFC 10031 verlangt von der CA, sicherzustellen, dass enthaltene MAC-Werte dem Subjektgerät während der Zertifikatslaufzeit gehören oder voraussichtlich gehören werden. Derselbe Wert soll nicht in Zertifikaten verschiedener Geräte stehen, außer diese teilen dieselbe Layer-2-Schnittstelle. Ein selbstsigniertes Zertifikat muss die Adresse eines physischen Ports verwenden.

Wie stark diese Bindung ist, hängt von der Prüfung ab. Fertigungsunterlagen, kontrollierte Registrierung, Schlüsselnachweis im Gerät, authentisiertes Inventar oder physische Kontrolle stützen unterschiedliche Aussagen. Die RFC weist ausdrücklich auf Spoofing hin. Dynamische Zuweisung und gemeinsame Nutzung schwächen Eindeutigkeit und Zurechenbarkeit.

Der Ausstellungsbeleg braucht Teilnehmer, Gerät und behauptete Schnittstelle, exakte Oktette, Methode und Zeitpunkt, Aussteller, Seriennummer, Gültigkeit und Sperrstatus. Die bloße Anwesenheit des Feldes sagt nicht, warum die CA den Anspruch akzeptiert hat.

Auch korrekte Prüfung altert. Ports werden ausgetauscht, virtuelle Interfaces neu erzeugt, Adressen rotiert oder neu zugewiesen. Das Zertifikat kann gültig bleiben, obwohl seine ursprüngliche Begründung nicht mehr stimmt. Sperrung wirkt nur, wenn Änderungen erkannt, gemeldet und von der vertrauenden Seite rechtzeitig ausgewertet werden.

Name Constraints begrenzen PKI-Namensräume

Für die neue Namensform definiert RFC 10031 Name Constraints aus Wert- und Maskenmuster. Die Codierung umfasst bei EUI-48 zwölf, bei EUI-64 sechzehn Oktette. CA-Zertifikate können damit erlaubte oder ausgeschlossene Teilräume für nachfolgende Zertifikate beschreiben.

Das ist kein Platzhalter im präsentierten Namen. Dort steht weiterhin ein vollständiger Wert, der exakt verglichen wird. Muster und Maske sind Teil der Zertifikatspfadentscheidung.

RFC 5280 setzt die Grenze: Name Constraints stehen in CA-Zertifikaten und beschränken Namen späterer Zertifikate im Pfad. Sie erfassen subjectAltName, wenn die jeweilige Namensform vorhanden ist, und werden im Allgemeinen nicht auf selbst ausgestellte Zertifikate angewandt, außer das selbst ausgestellte Zertifikat ist das letzte im Pfad.

Eine erfolgreiche Prüfung bedeutet, dass der Name unter einem bestimmten Vertrauensanker, Pfad, Regelwerk und Zeitpunkt in den zulässigen Raum fällt. Sie weist keine IEEE-Zuweisung, keinen aktuellen Port, keine Framequelle und keine VLAN-Berechtigung nach. Die Maske ordnet Delegation in der PKI; sie verhindert keine Wiederverwendung in getrennten lokalen Netzen.

Der Pfadnachweis umfasst daher Vertrauensanker, Kette, Policy, Zeitpunkt, exakten SAN-Wert, erlaubte und ausgeschlossene Constraints sowie Sperrinformationen. Er ist eine kryptografische Entscheidung, kein Switch-Readback.

Der beobachtete Wert gehört zu einem lokalen Moment

MAC-Adressen haben gewöhnlich lokalen Geltungsbereich. RFC 10031 warnt davor, ohne weitere Belege Eindeutigkeit über das lokale Netz hinaus anzunehmen, weil diese Werte normalerweise keine Layer-3-Grenze passieren. Zwei getrennte Netze können denselben lokalen Wert legitim verwenden. Im selben Netz kann ein Duplikat durch Fehler, Klonen oder Angriff entstehen.

Die vertrauende Anwendung muss deshalb das Zertifikatsereignis mit der Netzbeobachtung verbinden: Authentisierungsprotokoll und Ergebnis, Schlüsselnachweis, beobachtete Quell-MAC, physische oder logische Schnittstelle, Anschlusspunkt, VLAN oder vergleichbarer Bereich, Zuweisungs- oder Randomisierungszustand, Duplikaterkennung und Zeit.

Byte-Gleichheit bedeutet dann genau, dass der präsentierte Wert dem Zertifikatsnamen entspricht. Sie beweist nicht, dass alle späteren Frames aus derselben Hardware kommen, die Firmware unversehrt ist oder eine bestimmte Person das Gerät nutzt. Diese Behauptungen benötigen weitere Signale.

Running-Code Primacy hält die Ebenen auseinander: Der Standard koordiniert Syntax, die PKI liefert eine signierte Behauptung, das laufende Netz liefert Beobachtung und Resultat. Ein Schema wird nicht dadurch schwächer, dass es seinen Beweisbereich ehrlich begrenzt.

Lokale Autorisierung bleibt ein eigener Akt

Ein erfolgreich authentisiertes Gerät kann weiterhin abgewiesen werden. Es befindet sich vielleicht am falschen Port, verlangt eine unzulässige Aktion, ist in Quarantäne oder hat sein Wartungsfenster überschritten. Das ist ein Autorisierungsergebnis, kein nachträglicher Fehler des Zertifikatspfads.

Der Berechtigungsbeleg braucht Regel, Eigentümer, Version, bewertete Merkmale, erlaubte Aktion, Bereich, Ablauf, Ausnahme und Resultat. Bei manueller Übersteuerung sind Person und Grund festzuhalten. Sonst erscheint die CA als Netzadministrator, obwohl sie nie über die lokale Handlung entschieden hat.

Eine minimale gemeinsame Spezifikation ist gerade wegen ihrer Begrenzung nützlich. Sie liefert einen portablen Namen und einen Constraint-Mechanismus. Prüfqualität, zulässiger Adressraum, Kollisionen, Beobachtung und Durchsetzung verbleiben beim Betreiber, der das Risiko trägt.

Stabile Sicherheitssignale sind stabile Tracking-Signale

RFC 10031 warnt, dass ein stabiler MAC-Wert im Zertifikat die langfristige Verfolgung eines Geräts oder Nutzers erleichtern kann. Adressrotation, kurzlebige Zertifikate oder Randomisierung sollen erwogen werden, sofern sie machbar sind.

RFC 6973 bezeichnet das Zusammenführen personenbezogener Informationen als Korrelation und die Identifikation eines Geräts oder einer Anwendungsinstanz aus mehreren Merkmalen als Fingerprinting. Dauerhafte Kennungen auf jeder Schicht, darunter Geräte-ID oder Zertifikat, können Kommunikation über Zeit verbinden.

Verschlüsselung hebt diese Fähigkeit nicht zwingend auf. Zertifikate und Authentisierungslogs können sichtbar sein, gespeichert und mit anderen stabilen Feldern verknüpft werden. Umgekehrt ist Randomisierung keine universelle Lösung: Manche Layer-2-Steuerungen brauchen Stabilität, und eine Adressrotation kann der Zertifikatslaufzeit widersprechen.

Der Datenschutzbeleg sollte Zweck, Beobachter, Bereich, Laufzeit von Adresse und Zertifikat, verknüpfbare Felder, geprüfte Rotationsmöglichkeit und Löschung dokumentieren. Kryptografischer Schutz macht eine dauerhafte Kennung nicht datenschutzneutral.

Die sechs Belege der Entscheidung

Eine nachvollziehbare Architektur bewahrt sechs Aussagen: Warum der Wert nach IEEE- oder lokaler Regel verfügbar war; warum die CA ihn gebunden hat; warum der Pfad ihn akzeptierte; welche Schnittstelle und welches Ereignis beobachtet wurden; warum die lokale Regel eine Aktion erlaubte; und wie lange die kombinierte Spur verknüpfbar bleibt.

Jeder Übergang kann scheitern. Gültig zugewiesen heißt nicht sauber registriert. Korrekt ausgestellt heißt nicht ungesperrt. Gültiger Pfad schließt Spoofing nicht aus. Echtes Gerät heißt nicht berechtigtes Gerät. Erlaubter Zugang kann trotzdem zu lange protokolliert werden.

RFC 10031 schafft einen exakten Namen, an dem diese Belege zusammengeführt werden können. Sie schafft keine Abkürzung, mit der man sie weglassen dürfte.

Quellen