Zusammenfassung

  • RFC 9640 definiert wiederverwendbare YANG-Typen und Gruppierungen für Passwörter, Schlüssel, Zertifikate, verschlüsselte Werte und Zertifikatsanfragen.
  • Ein akzeptierter Schlüsselzustand belegt nicht, wie und wo der Schlüssel erzeugt oder importiert wurde und welche Grenze ihn tatsächlich verwahrt.
  • Ein belastbarer Nachweis verbindet Sitzung, NACM, Genehmigung, Datastore, Herkunft, Nutzungsrechte, Laufzeitwirkung und Lebenszyklus.

Ein externer Client schrieb einen privaten Schlüssel in die Konfiguration. Der Server akzeptierte ihn, verbarg seinen Wert und meldete einen erfolgreichen Commit. Monate später lautete die Inventaraussage: „auf dem Gerät sicher erzeugt“.

Die YANG-Historie stützte diesen Satz nicht. RFC 9640 stellt gemeinsame kryptografische Bausteine bereit, lässt die Erzeugung versteckter Schlüssel aber außerhalb der Gruppierung. Frühere generische RPCs zur Schlüsselerzeugung wurden entfernt, weil kein Konsens zur Algorithmuskennzeichnung bestand. Spezifische Module dürfen eigene Aktionen ergänzen.

Präzise Form, begrenzte Aussage

Das im Oktober 2024 veröffentlichte Standards-Track-Dokument definiert ietf-crypto-types. DER-codierte ASN.1-Objekte umfassen PKCS #10, X.509-Zertifikate, Sperrlisten, OCSP und CMS. Gruppierungen decken Passwort, symmetrischen Schlüssel, öffentlichen und privaten Schlüssel, asymmetrisches Paar, Zertifikat, verschlüsselten Wert und CSR-Erzeugung ab.

Diese gemeinsame Sprache ist eine Mindestarchitektur. Vollständige Truststore- und Keystore-Modelle stehen in RFC 9641 und RFC 9642. Der Baum kann zeigen, welches Objekt ein Server unter einer Revision und einem Feature-Satz akzeptiert hat. Für Herkunft braucht es zusätzlich Auftrag, Algorithmuspolitik, Entropie- und Gerätebeleg, Attestation, Importkanal, Beteiligte und Fingerprint.

Unsichtbar ist nicht universell unexportierbar

Klartextspeicherung ist feature-gesteuert und nicht empfohlen. Lesbare Geheimnisse tragen nacm:default-deny-all, Schreibvorgänge default-deny-write. Ein versteckter Schlüssel ist über Managementschnittstellen nicht abrufbar, bleibt dem Server aber für Kryptografie verfügbar.

Diese Definition sagt nichts über HSM-Residenz. Lokale APIs, privilegierte Prozesse, Speicherabbilder oder Sicherungsfunktionen können andere Grenzen besitzen. Wer Nicht-Extrahierbarkeit behauptet, muss Implementierung, Objektattribute, Firmware, Schnittstellen, Rollen, Backupverhalten, Attestation und Negativtests nennen.

Verschlüsselung verschiebt die Verwahrfrage. CMS beschreibt den Container; AEAD oder CBC mit zufälligem IV sind bei symmetrischer Verschlüsselung erforderlich, ECB ist verboten. Der leere encrypted-by-Container muss vom nutzenden Modul um die Referenz zum Wrapping Key ergänzt werden. Dessen Schutz, Verfügbarkeit, Rotation und Berechtigung bleiben separat nachzuweisen.

Zugriffsvorgabe und Zugriffsereignis

Restriktive NACM-Vorgaben sind wertvoll, aber keine Chronik. Ein Nachweis nennt NETCONF- oder RESTCONF-Sitzung, Gegenstelle, Channel Binding, aktive Regelversion, getroffene Regel, Pfad und Operation, Zustand vorher und nachher, Commit sowie geschäftliche Freigabe. Transportauthentisierung, Modellberechtigung und organisatorisches Mandat sind verschiedene Entscheidungen.

Auch mathematische Konsistenz bleibt begrenzt. Der Server muss ein geliefertes öffentlich-privates Paar und zugehörige Zertifikate auf Übereinstimmung prüfen. Das verhindert falsche Kombinationen, beweist aber weder regelkonforme Erzeugung noch rechtmäßige Ausstellung oder beabsichtigte Nutzung. Die generischen Gruppierungen begrenzen Signatur, Entschlüsselung, Verifikation und Verschlüsselung nicht; das muss die Anwendungspolitik leisten.

Die CSR-Aktion ist standardmäßig vollständig gesperrt, und Channel Binding wird empfohlen. Ein ausgegebener CSR ist trotzdem erst eine Anfrage. CA-Einreichung, Prüfung, Ausstellung, Installation und erste verifizierte Nutzung bilden weitere Belegschritte.

Löschen und Vernichten

Klartextschlüssel sollen bei Löschung nullgesetzt werden. Verschwindet der YANG-Knoten, ist zunächst nur die Datastore-Transition sichtbar. Prozessspeicher, Journal, Replik, Swap, Crashdump und Backup können fortbestehen.

Ein Vernichtungsnachweis erfasst Serverversion, Speicher- und Replikationsdomänen, Löschtransaktion, Überschreib- oder Hardwaremechanismus, Offline-Repliken, Backupablauf und Prüfverfahren. Kann eine Ebene nicht bestätigt werden, bleibt die Aussage bewusst enger.

Der vollständige Verwahrnachweis verbindet Modulrevision und Features mit Sitzung, NACM, Freigabe, Commit, Erzeugung oder Import, Vertrauensgrenze, erlaubten Operationen, Wrapping-Abhängigkeit, tatsächlicher Nutzung, Rotation, Widerruf und Vernichtung. Das Modell beschreibt; laufender Code bewirkt; Protokolle bewahren Verantwortung.

Quellen