Zusammenfassung

  • BRSKI-AE verbindet den Besitznachweis für den neuen Schlüssel mit einem Herkunftsnachweis auf Basis der werkseitigen IDevID. Eine entfernte RA kann beides nach Zwischenspeicherung und Weiterleitung selbst prüfen.
  • Das signierte Objekt ermöglicht eine Autorisierungsentscheidung, trifft sie aber nicht. Auch bei ausgelagerter RA bleibt der Domain Registrar nach RFC 9733 am Beitritt zur Domäne beteiligt.
  • Voucher, Registrar-Zustimmung, RA-Entscheid, CA-Ausstellung, Zertifikatsbestätigung, Enrollment-Telemetrie und produktiver Zugang sind getrennte Belege. Ein pauschales „Onboarding erfolgreich“ verwischt diese Kette.

Die Verbindung einer Außenanlage zur zentralen PKI fiel aus, kurz nachdem ein neues Gerät seinen Registrar gefunden hatte. Der Antrag blieb vor Ort liegen und wurde erst später über mehrere Systeme transportiert. Als die zentrale Registrierungsstelle ihn erhielt, war die ursprüngliche TLS-Verbindung längst beendet. Trotzdem musste sie feststellen können, ob genau dieses Gerät genau diesen Schlüssel beantragt hatte.

RFC 9733 macht die Antwort vom Fortbestand der ersten Sitzung unabhängig. BRSKI with Alternative Enrollment verwendet authentisierte, in sich geschlossene Zertifizierungsobjekte. Der Antrag enthält einen Nachweis über den Besitz des neuen privaten Schlüssels und einen zweiten Nachweis über seinen Ursprung bei dem mit einer IDevID ausgestatteten Pledge.

Damit kann Evidenz warten und reisen. Entscheidungsmacht reist nicht automatisch mit. Der Antrag wählt keine Domäne, genehmigt seine eigenen Attribute nicht und zwingt keine Zertifizierungsstelle zur Ausstellung. Er bleibt Eingabe für mehrere Instanzen, die jeweils einen anderen Satz verantworten.

Besitz ist nicht Herkunft

Der Proof of Possession beantwortet eine technische Schlüsselfrage. Ein PKCS-#10-Antrag wird üblicherweise mit dem neu erzeugten privaten Schlüssel signiert. CRMF bietet weitere Verfahren, auch für Schlüsseltypen ohne Signaturfähigkeit. Ein positiver Test zeigt, dass der Antragsteller den zum öffentlichen Schlüssel gehörenden geheimen Wert kontrolliert.

Er sagt nicht, wer der Antragsteller ist. Jeder kann ein neues Schlüsselpaar erzeugen und dessen Besitz beweisen. Der Proof of Identity oder Proof of Origin bindet den Antrag deshalb an ein bereits authentisiertes Merkmal. Im BRSKI-AE-Kontext schützt typischerweise der IDevID-Schlüssel eine Nachricht, die auch einen belastbaren Geräteidentifikator enthält.

Beide Ergebnisse können auseinanderfallen. Ein Angreifer besitzt seinen eigenen Schlüssel korrekt, ohne eine berechtigte IDevID zu haben. Ein echtes Gerät kann einen unzulässigen Namen oder eine zu weit reichende Verwendung verlangen. Selbst zwei gültige kryptografische Prüfungen ersetzen keine Prüfung von Eigentum, Inventar, Sperrstatus oder Domänenpolitik.

Ein Prüfpfad sollte daher Schlüsselbesitz, Herkunft und Autorisierung getrennt speichern. „Signatur gültig“ ist weder eine vollständige Begründung für die Ausstellung noch eine brauchbare Fehlerdiagnose.

Der erste TLS-Hop darf nicht der einzige Zeuge bleiben

Im klassischen BRSKI kann EST einen PKCS-#10-Antrag an die Client-Authentisierung der TLS-Sitzung zwischen Pledge und Registrar binden. Für den unmittelbaren Registrar ist das wertvoll. Eine zweite, dahinterliegende RA sieht diese flüchtige Sitzung jedoch nicht zwangsläufig und kann die Bindung nicht selbst nachvollziehen.

BRSKI-AE nutzt Enrollment-Protokolle, deren Nachrichten sich selbst authentisieren. Die normative Variante setzt CMP im Lightweight CMP Profile ein. Der PKIMessage-Schutz trägt den IDevID-Ursprung, während CRMF oder PKCS #10 den Besitz des künftigen LDevID-Schlüssels belegt. Der Registrar leitet das Original weiter, statt aus einer vergangenen Sitzung eine bloße Behauptung zu machen.

Dadurch kann ein lokaler Registrar Gatekeeper bleiben, während eine zentrale RA mit umfangreicheren Informationen prüft und eine CA ausstellt. Ein Store-and-forward-System transportiert überprüfbare Evidenz; es muss nicht zur Identitätsinstanz werden.

Transportunabhängigkeit ist jedoch keine Transportgleichgültigkeit. Zwischen Pledge und Registrar bleibt der bestehende TLS- oder DTLS-Kanal vorgeschrieben. Die Strecke vom Registrar zur Backend-PKI liegt außerhalb des Dokuments. CMP schützt Authentizität und Integrität, verschlüsselt die Nachricht aber nicht von selbst. Ohne zusätzlichen Schutz kann ein Beobachter erkennen, welche Geräte aufgenommen werden, oder einzelne Anmeldungen blockieren.

Der Voucher verankert die Domäne, nicht die LDevID-Berechtigung

Vor dem alternativen Enrollment führt der Pledge den BRSKI-Voucher-Austausch über Registrar und MASA durch. Der Voucher liefert den Vertrauensanker für die Zieldomäne, häufig das pinned-domain-cert. Damit kann das Gerät die Instanzen authentisieren, von denen es Domänenmaterial akzeptieren soll.

Der Voucher ist aber kein LDevID-Zertifikat. Er beweist weder die spätere Zustimmung der RA noch die CA-Ausstellung oder den Netzzugang. Seine Aussage lautet, welcher Domäne der Pledge vertrauen darf, nicht welche Berechtigung diese Domäne bereits erteilt hat.

Nach dem Imprint erzeugt der Pledge das LDevID-Geheimnis und stellt den selbsttragenden Antrag. In der CMP-Ausprägung prüft er die Antwort gegen den durch den Voucher etablierten Anker. Die Beweisketten greifen ineinander: Der Voucher begrenzt das akzeptierte Vertrauen, die PKI entscheidet über einen konkreten Schlüssel und konkrete Attribute.

Eine Anzeige, die einen angenommenen Voucher als „Gerät zugelassen“ meldet, springt über die eigentliche Entscheidung. Eine Anzeige, die nur das Zertifikat kennt, verliert dagegen die Begründung, warum der Pledge diesem Aussteller vertraute.

Ausgelagerte Prüfung darf den Registrar nicht umgehen

RFC 9733 gestattet dem Registrar, Teile oder die gesamte RA-Funktion an ein separates System abzugeben. Gleichwohl muss er an der Entscheidung über den Domänenbeitritt teilnehmen. Der Pledge darf nicht an ihm vorbei ein LDevID von der CA beschaffen.

Zustimmung kann in einer streng beherrschten Beziehung implizit sein, außerhalb des Nachrichtenflusses hinterlegt, als zusätzliche Nachricht übertragen oder explizit signiert werden. Für CMP empfiehlt der RFC, den ursprünglichen Pledge-Antrag in eine vom Registrar signierte verschachtelte Nachricht aufzunehmen. Das Backend sieht dann zwei eigenständige Aussagen: Das Gerät hat diesen Inhalt erzeugt; die Domäne stimmt seiner Prüfung zu.

Das Original verhindert, dass ein Vermittler den Antrag durch eine bequeme Zusammenfassung ersetzt. Die zusätzliche Registrar-Signatur verhindert, dass eine Herstelleridentität als lokale Erlaubnis gelesen wird. Die RA kann weiterhin ablehnen. Die CA stellt erst nach den geforderten Authentisierungs- und Autorisierungsschritten aus.

Auch Fehler werden zuordenbar: Ein IDevID-Problem betrifft die Herkunft, fehlende Zustimmung den Registrar, ein unzulässiges Profil die RA und ein falsches Zertifikat die CA. „PKI-Fehler“ allein benennt keinen reparierbaren Kontrollpunkt.

Eine Warteschlange konserviert keine Entscheidung

Für intermittierend verbundene Standorte ist ein selbstauthentisierender Antrag besonders nützlich. Er kann auf Übertragungskapazität warten, ohne seinen Ursprung zu verlieren. Währenddessen können sich Eigentum, Registrar-Zustimmung, Zertifikatsprofil oder Vertrauensanker ändern.

Ein Antrag kann ein zweites Mal eintreffen, weil die erste Antwort verloren ging. Seine alte Signatur bleibt mathematisch korrekt, obwohl das damalige Mandat nicht mehr gilt. Authentizität beantwortet, wer signiert hat; Aktualität beantwortet, ob die Signatur heute noch eine Wirkung auslösen darf.

Ein belastbarer Transaktionsdatensatz verbindet daher Voucher-Identität, Schlüsselfingerabdruck, Besitz- und Herkunftsprüfung, beantragte Attribute, Registrar-Zustimmung, Backend-Transaktionskennung, RA-Entscheid, CA-Antwort und Zertifikatsfingerabdruck. Ein Retry muss eine verlorene Antwort von einem nie genehmigten Antrag unterscheiden. Das Alter der Warteschlange gehört in die Richtlinie.

Eine CA-Antwort beendet nicht jede Kette

Die erfolgreiche Zertifizierungsantwort enthält das Zertifikat und kann Zwischenzertifikate oder weitere Anker mitführen. CMP erlaubt anschließend ein optionales Certificate Confirm. Der Pledge meldet nach der Prüfung positiv oder negativ, ob das Zertifikat erfolgreich enrolled wurde und seinen Anforderungen entspricht. PKI oder Registrar bestätigen den Empfang.

Daneben bleibt die obligatorische BRSKI-Enrollment-Status-Telemetrie zwischen Pledge und Registrar bestehen. RFC 9733 bezeichnet sie ausdrücklich als eigene Schlussphase. Die CMP-Bestätigung informiert die PKI über die Bewertung des Zertifikats; die BRSKI-Telemetrie informiert den Registrar über den Enrollment-Ausgang. Eine Empfangsbestätigung ist kein Nutzungsbeleg.

Installation, Netzzugang, Konfiguration und Dienstwirkung folgen außerhalb dieses Austauschs. Eine CA kann korrekt ausstellen, obwohl das Gerät das Zertifikat nie verwendet. Der Pledge kann Erfolg melden und die Zugangskontrolle dennoch ablehnen. Die Netzaufnahme kann gelingen und die beabsichtigte Anlagenfunktion ausfallen.

Der ehrliche Status nennt die Grenze: Voucher angenommen; Besitz und Ursprung geprüft; Registrar-Zustimmung gespeichert; RA genehmigt; CA ausgestellt; Pledge bestätigt; Telemetrie empfangen; Betriebszulassung noch nicht beobachtet.

Ein Dienstname findet eine Funktion, keine legitime Autorität

RFC 9733 verallgemeinert Endpunkte zu /.well-known/<enrollment-protocol>/<request> und registriert brski-reg-cmp als minimalistischen Fundmechanismus für CMP-fähige Registrars. Der Pledge kann den Endpunkt ansprechen und anhand des HTTP-Status Unterstützung erkennen.

Das ist Capability Discovery. Es beweist nicht, dass der gefundene Registrar für diesen Pledge legitim ist. Eine IANA-Registrierung belegt weder Deployment noch Konformität. Ein HTTP-Erfolg kann nur den äußeren Empfang anzeigen, während die CMP-Transaktion wartet oder scheitert. Endpunkt, TLS-Peer, Domänenanker, Protokoll, innere Transaktion und Entscheider müssen korreliert bleiben.

Die eingefrorenen Quellen belegen keine RFC-9733-Produktivnutzung bei einem bestimmten Hersteller, Bahnunternehmen, Umspannwerk, Gebäude oder Ladenetz. Die Beispiele motivieren die Architektur; sie sind keine Marktbeobachtung.

Quellen