Zusammenfassung

  • RFC 9646 setzt zwischen zwei get-bootstrapping-data-Aufrufen eine HTTP-400-Antwort; Fähigkeitsmeldung, Serverauswahl und zurückgesandter CSR sind verschiedene Belege.
  • Die CSR-Signatur beweist den Besitz des zugehörigen privaten Schlüssels, aber nicht allein den Ursprung, die CA-Freigabe, die Zustellung, Installation oder berechtigte Nutzung.
  • Weil csr-request in einer HTTP-Fehlermeldung steckt, die nicht wie RFC-8572-Bootstrapdaten signiert werden kann, ist das Verfahren gegenüber einem nicht vertrauenswürdigen Bootstrap-Server unzulässig.

Der gültige CSR kam zu früh im Bericht

RFC 9646 erweitert Secure Zero Touch Provisioning um die Möglichkeit, während des Onboardings ein für die Produktionsumgebung bestimmtes Identitätszertifikat zu erhalten. Dafür entsteht eine Folge aus zwei Anfragen und einer ungewöhnlichen Zwischenantwort.

Zuerst sendet der SZTP-Client csr-support. Er meldet, ob er ein neues asymmetrisches Schlüsselpaar erzeugen kann, welche Algorithmen er unterstützt und welche CSR-Formate er erstellen kann. Will der Server einen Antrag, antwortet er mit HTTP 400 und legt csr-request in RESTCONF error-info ab. Dort wählt er Algorithmus und Format und kann Zertifikatsinformationen vorgeben.

Der Client sendet danach einen zweiten get-bootstrapping-data-Aufruf mit p10-csr, cmc-csr oder cmp-csr. Server, Registrierungsstelle oder Zertifizierungsstelle prüfen den Antrag. Erst eine positive Richtlinienentscheidung führt zu Onboarding-Informationen, die das signierte Zertifikat enthalten können.

HTTP 400 bleibt formal ein Client-Fehlerstatus und ist zugleich der erwartete Arbeitsauftrag dieses Protokollzweigs. Es ist weder das endgültige Scheitern noch die Genehmigung der Identität.

Die Liste der Möglichkeiten ist kein Ausführungsnachweis

csr-support beschreibt, was der Client nach eigener Aussage leisten kann. Es belegt keine Schlüsselerzeugung, keine ausreichende Zufallsquelle und keinen Verbleib des privaten Schlüssels im TPM. Die Serverauswahl verengt die Möglichkeiten, ist aber nur eine Anweisung. Erst der zweite Aufruf zeigt, dass ein Objekt erzeugt wurde.

Lu Hengs Minimum Initial Specification liefert den passenden Maßstab: Das gemeinsame Protokoll standardisiert den notwendigen Übergabepunkt; lokale Entscheidungen bleiben als solche erkennbar. RFC 9646 definiert weder eine universelle CA-Richtlinie noch einen einzigen Zertifikatstransport oder eine Anwendungsberechtigung.

Ein Feld „CSR abgeschlossen“ kann nicht erklären, ob der Server einen angekündigten Algorithmus auswählte, ob ein angeblich neuer Schlüssel schon existierte oder ob beide Anfragen tatsächlich zur selben Runde gehörten.

Besitz und Ursprung verlangen getrennte Prüfungen

Für den Besitznachweis wird die CSR-Signatur mit dem im Antrag enthaltenen öffentlichen Schlüssel geprüft. Ein positives Ergebnis zeigt: Der Ersteller kontrollierte den zugehörigen privaten Schlüssel. Mehr sagt es nicht.

Der Ursprung fragt nach dem Gerät oder berechtigten Prinzipal hinter dem Antrag. Ein roher PKCS-#10-CSR enthält keine eigene Ursprungsauthentisierung. Sie kann aus der TLS- oder HTTP-Identität der Sitzung stammen. Dann muss diese Sitzung dauerhaft an den CSR gebunden bleiben. Eine isolierte Datei kann den verlorenen Kontext nicht ersetzen.

CMC und CMP unterstützen Ursprungsauthentisierung per PKI oder gemeinsamem Geheimnis und können eine Registrierungsstelle vor die CA schalten. Das schafft bessere Beweismöglichkeiten, aber keine automatische Genehmigung. IDevID-Pfad, Geheimnisreferenz oder Protokollschutz sind zu prüfen; danach folgt die Ausstellungsrichtlinie.

Bei Wiederverwendung des Herstellerschlüssels wird der IDevID-Zertifizierungspfad validiert und die Identität des Schlüsselpaars bestätigt. Bei einem frischen lokalen Schlüssel können CMC oder CMP die neue Anfrage mit Herstelleridentität oder Geheimnis verbinden. Beide Pfade unter „Signatur gültig“ zusammenzufassen verschleiert ihre Verantwortung.

Frische und Verwahrung lösen unterschiedliche Risiken

RFC 9646 empfiehlt für jeden CSR einen neuen privaten Schlüssel. Wird er nach dem Serverauftrag tatsächlich erzeugt, wirkt sein Zufall zugleich nonce-ähnlich. Enthält das zurückgelieferte Zertifikat den neuen öffentlichen Schlüssel, kann der Client die Antwort der aktuellen Runde zuordnen.

Die Anzeige key-generation genügt dafür nicht; ein wiederholter Fingerabdruck widerlegt die Frische. Ein neuer Schlüssel ist zudem nicht automatisch sicherer. Kann das Gerät ihn nicht so gut schützen wie den eingebauten Herstellerschlüssel, empfiehlt der RFC die Wiederverwendung des besser geschützten Schlüssels. Frische begrenzt bestimmte Replay-Risiken; starke Verwahrung begrenzt Schlüsseloffenlegung.

Der dynamische Schlüssel muss geschützt werden, vorzugsweise in HSM oder TPM. Ohne gleichwertige Grenze verkürzt Rotation die Expositionsdauer. Deployment-Zertifikat und frischer Schlüssel sind Nutzerdaten und sollten beim Werksreset gelöscht werden. Eine Beweiskette endet deshalb nicht bei der Ausstellung.

Die unsignierte Nachricht setzt die Vertrauensgrenze

RFC 8572 kennt den Fall, dass ein Client einen noch nicht vertrauenswürdigen Bootstrap-Server kontaktiert und sich auf signierte Bootstrapdaten stützt. Für csr-request funktioniert das nicht. Der Auftrag liegt in einer HTTP-Fehlermeldung, die nicht als Bootstrapdaten signiert werden kann.

Darum darf der CSR-Mechanismus gegenüber einem nicht vertrauenswürdigen Server nicht eingesetzt werden. Der Client sollte dort kein csr-support, sondern signed-data-preferred senden. Die Grenze betrifft Autorität, nicht bloß Protokollhygiene.

Wer sie überschreitet, lässt eine nicht authentisierte Partei Algorithmus, Format und Inhalt der künftigen Produktionsidentität prägen. Ein später mathematisch gültiger CSR beweist lediglich die Befolgung des Auftrags. Er legitimiert den Auftraggeber nicht rückwirkend.

Ausstellung ist nicht Zustellung

Nach Eingang des CSR prüfen Server, RA oder CA Besitz, Ursprung, Bestand und gewünschte Attribute. Die Institution genehmigt oder verweigert. Die CSR-Signatur ersetzt diese Entscheidung nicht.

RFC 9646 lässt offen, wie das signierte Zertifikat innerhalb der Onboarding-Informationen transportiert wird. Beispiele zeigen unter anderem eine Zuordnung zum RFC-9642-Keystore. Sie machen aus einem Transportweg keine Installationsbestätigung.

Installation verlangt die Bindung an den richtigen Schlüssel, einen bestätigten Schreibvorgang und die Auswahl durch den vorgesehenen Dienst. Die erste erfolgreiche Peer-Validierung ist ein weiterer Beleg. Danach bleibt die Anwendungsautorisierung eine eigene Entscheidung.

Lu Hengs Running-Code Primacy priorisiert ausgeführte Übergänge und sichtbare Wirkungen. YANG beschreibt den Austausch; CA, Datenspeicher und Dienst erzeugen jeweils ihre eigenen Tatsachen.

Der vollständige Enrollment-Beleg

Er beginnt mit Serveridentität, Vertrauensankerpfad, TLS- und HTTP-Authentisierung sowie der Entscheidung für csr-support oder signed-data-preferred. Die erste Anfrage bewahrt Nonce, Geräteinformationen, Algorithmen und Formate.

HTTP 400 wird als Protokollübergang mit vollständigem csr-request, Auswahl, Inhalt, Zeit und Korrelationskennung gespeichert. Für den Schlüssel bleiben Erzeugung oder Wiederverwendung, öffentlicher Fingerabdruck, Zufalls- oder HSM-Nachweis, Schutzgrenze und Frischeurteil erhalten.

Die zweite Anfrage liefert Format und Hash des CSR. Besitz und Ursprung erhalten getrennte Urteile mit IDevID-Pfad, Geheimnis, TLS- oder HTTP-Identität. Danach folgen RA/CA-Entscheidung, Zertifikatsfingerabdruck, Transport, Installation, erste Nutzung, Rotation und Löschung.

Die Realitätsebenen verhindern geliehene Autorität: Statuscode, Protokollauftrag, Schlüsselbesitz, Ursprung, institutionelle Freigabe, installierter Zustand und Betriebsergebnis liegen nebeneinander, sind aber nicht dasselbe.

Sources