Zusammenfassung

  • RFC 9642 standardisiert einen YANG-Keystore für symmetrische und asymmetrische Schlüssel, Zertifikate, zentrale Referenzen und Inline-Definitionen; es bescheinigt keinen operativen Wiederanlauf.
  • Verschlüsselte Konfiguration ist nur dann portabel, wenn gemeinsamer KEK, gerätespezifische Primärschlüssel, Rewrapping und Berechtigung einen geschlossenen Abhängigkeitsgraphen bilden.
  • Der Beleg reicht bis zum Verbraucher: richtige Referenz, richtiges Zertifikat, ausgeführte zulässige Operation, abgewiesene unzulässige Nutzung und beobachtetes Dienstergebnis.

Der neue Server meldete einen erfolgreichen Konfigurationsimport. Die verschlüsselten Schlüssel hatten dieselben Hashes wie im Backup. Erst der Funktionstest zeigte, dass der private Schlüssel an eine Hardwaregrenze des alten Systems gebunden war und der neue Primärschlüssel den gemeinsamen KEK nie erhalten hatte.

Die gespeicherten Bytes waren korrekt; ihre Nutzbarkeit war nicht mitgewandert. RFC 9642 macht diesen Unterschied sichtbar, wenn man das Modell als gemeinsame Beschreibung und nicht als Ergebniszertifikat liest.

Modellkonformität hat mehrere Ausprägungen

RFC 9642 wurde im Oktober 2024 auf dem IETF Standards Track veröffentlicht. Zentraler Keystore, Inline-Definitionen, asymmetrische und symmetrische Schlüssel sind getrennte Features. Verbrauchende Module können zwischen Inline-Material und zentraler Referenz wählen sowie weitere Speicherorte ergänzen.

Darum muss ein Beleg Revision, Features, YANG Library, Datastore, vollständigen Pfad, Objekt-Hash und Verbraucher festhalten. Ein Listenname identifiziert innerhalb einer Instanz; er ist kein globaler Schlüsselname, keine Eigentumsaussage und kein Nutzungsnachweis.

Eine auflösbare leafref belegt eine Konfigurationsverbindung. Ob der laufende Prozess genau diese Revision geladen, eine Inline-Alternative bevorzugt oder eine Operation mit dem Objekt ausgeführt hat, bleibt offen.

Systemherkunft ist keine Lieferkette

Gemäß RFC 8342 können eingebaute Schlüssel in <operational> und <system> mit Systemherkunft erscheinen. Sie können bei der Herstellung gesetzt, beim ersten Start oder beim Aktivieren eines Dienstes erzeugt worden sein.

Die Annotation trennt serverbereitgestellte von operatorgeschriebenen Daten. Sie belegt weder Erzeuger noch Entropie, Hardwarebindung, Exportierbarkeit, Firmwarestand oder Gültigkeit des Identitätszertifikats. Wie eingebaute Schlüssel gesetzt und geändert werden, liegt außerhalb des RFC.

Kommt später ein betriebliches Zertifikat hinzu, treffen zwei Herkunftslinien zusammen. Eine flache Exportdarstellung verliert diese Trennung. Der Wiederanlaufbeleg bewahrt Ursprung des Schlüssels, jedes Zertifikats und der Verknüpfung.

Die Verschlüsselungskante gehört zum Backup

Ein verschlüsseltes Objekt enthält Format, Ciphertext und die Referenz zum verschlüsselnden Schlüssel. Der Server benötigt Zugriff auf den KEK oder eine API, die ihn verwendet. Ohne diese Fähigkeit ist das Objekt vollständig, aber inaktiv.

Der nicht normative Migrationsablauf von RFC 9642 verschlüsselt viele Schlüssel unter einem gemeinsamen KEK. Dieser wird unter einem gerätespezifischen eingebauten Primärschlüssel geschützt. Beim Umzug wird nur der gemeinsame KEK für den Primärschlüssel des Zielsystems neu verpackt; die übrigen Ciphertexts können gleich bleiben.

Die Effizienz konzentriert Macht und Ausfallrisiko. Ein verlorener KEK blockiert viele Verbraucher. Eine Ersetzung verändert ihre Grundlage gemeinsam. Ein zu breit zugängliches KEK-API erweitert Befugnisse. Vollständigkeit bedeutet daher Graphschluss: sämtliche Ciphertexts, encrypted-by-Kanten, Primärschlüssel, KEK, Formate, Algorithmen, autorisierte Rewrapping-Aktion, Ergebnis und Rückfallobjekt.

Die RFC-Skizze ist kein Nachweis für ein bestimmtes Produkt. Der Bericht nennt Backup-Hash, Quell- und Zielsystem, Schlüsselidentitäten, Genehmigung, Zwei-Personen-Kontrolle, Tests und Rollback.

Hidden und encrypted bleiben begrenzte Aussagen

RFC 9640 liefert die Formen, die der Keystore nutzt. Hidden bedeutet, dass die modellierte Management-Schnittstelle den Geheimwert nicht liefert. Es bedeutet nicht, dass Speicher, lokale Werkzeuge, Backups oder Hardware keinen Exportweg haben. Encrypted sagt nichts darüber, ob der KEK geschützt und nach einer Störung verfügbar ist.

RFC 9642 empfiehlt Verschlüsselung persistierter Inhalte und Zeroisierung entschlüsselter flüchtiger Kopien nach Gebrauch. Unverschlüsselte Persistenz muss unzugänglich sein. Der YANG-Baum beobachtet keine Replikate, Swap-Dateien, Crash Dumps, Logs oder lokalen Privilegien.

Der Beleg ergänzt daher Speicherabdeckung, Umgang mit RAM, Kopieninventar, Zugriffsnachweise und Negativtests. Ohne Hardwarebeleg bleibt die Aussage auf die beobachtete Oberfläche beschränkt.

NACM ist eine Schranke, keine Chronik

Alle schreibbaren Knoten tragen nacm:default-deny-write; lesbare Geheimnisse erben strengere Sperren. RFC 8341 stellt den Mechanismus bereit, protokolliert aber nicht automatisch Sitzung, Regel und Ausnahme des konkreten Ereignisses.

Die Änderungsspur verbindet NETCONF-/RESTCONF-Identität, Kanal, NACM-Version, passende Regel, Pfad, Vorher/Nachher, Commit, Freigabe und operative Projektion. Lokale, hersteller- oder hardwareseitige Wege außerhalb YANG werden ebenfalls benannt. RFC 6241 und RFC 8040 liefern Managementkontext, nicht die gesamte Schlüsselbiografie.

RFC 9642 definiert selbst keine RPCs oder Actions. Erzeugung kann in SSH-/TLS-Verbrauchermodellen oder extern durch einen Crypto Officer stattfinden. Der fertige Knoten beweist weder Zeremonie noch Autorisierung.

Zuordnung ist noch keine Aktivierung

Ein asymmetrischer Schlüssel kann mehrere Zertifikate tragen. Die End-Entity-Referenz wählt Schlüssel und Zertifikat gemeinsam. Verified Errata 8441 korrigiert einen kopierten Kommentar, der fälschlich von einem symmetrischen Schlüssel sprach; die Struktur war stets asymmetrisch.

RFC 9644 und RFC 9645 zeigen SSH-/TLS-Verbraucher. Der Beleg löst deren Referenz auf, bindet die Konfigurationsrevision und beobachtet Signatur, Entschlüsselung oder Sitzung mit dem ausgewählten Objekt.

Die Nutzung des privaten Schlüssels ist im Modul nicht auf Signatur oder Entschlüsselung beschränkt. Zertifikate können den öffentlichen Schlüssel begrenzen; Organisationsmandat und ausgeführte Operation bleiben eigenständige Entscheidungen. Ein Wiederanlauftest prüft Erfolg und unzulässige Ablehnung.

Ablaufmeldung beginnt die Rotation

Eine Ablaufmeldung beweist Datum, nicht Zustellung, Quittierung, Freigabe, Ersatz, Referenzänderung oder Erfolg danach. Ein altes Backup kann ein bereits ausgesondertes Zertifikat zurückbringen.

Die Kette führt vom Ereignis über Empfänger und Bestätigung zum neuen Zertifikat, Schlüsselpaar, Verbraucher und beobachteten Betrieb. Abweichungen zwischen zentral und inline bleiben sichtbar.

Der vollständige Wiederanlaufbeleg

Zuerst werden exaktes Backup, Quelle, Module, Features, Datastores, Origins, Fingerprints, Formate und alle Verschlüsselungskanten fixiert. Dann folgen beide Primärschlüssel, gemeinsamer KEK, autorisierte Rewrapping-Aktion und Ergebnis.

Am Ziel wird geprüft, ob der KEK notwendige Objekte öffnet, Referenzen die richtige Version wählen, Zertifikate passen, Verbraucher tatsächlich arbeiten und verbotene Operationen scheitern. Den Abschluss bilden ein begrenztes Dienstergebnis und unabhängiger Rollback.

RFC 9642 koordiniert als minimale gemeinsame Spezifikation die Form. Laufender Code übt Schlüsselgewalt aus. Erst der Beleg zeigt, wo beides im konkreten Wiederanlauf zusammenkam.

Quellen