Zusammenfassung

  • RFC 9802 standardisiert Kennungen und Kodierungen für HSS, XMSS und XMSSMT in X.509-Zertifikaten und Sperrlisten. Die bereits verbrauchten Einmalschlüsselindizes stehen nicht im Zertifikat.
  • Eine Signatur kann mathematisch gültig sein, obwohl der private Zustand zurückgesetzt oder auf mehrere Geräte verzweigt wurde. Die Kontinuität braucht deshalb einen separaten, monotonen und prüfbaren Beleg.

Zwei grüne Prüfungen, ein gebrochener Verlauf

Eine Zertifizierungsstelle sichert am Montag ein Gerät; der nächste Index lautet 41.200. Das Primärgerät signiert danach Zertifikate und Sperrlisten bis 41.259. Am Freitag wird nach einem Defekt das Montagsabbild eingespielt. Das Ersatzgerät signiert ein anderes Objekt erneut mit 41.200.

Öffentlicher Schlüssel, OID und ASN.1-Struktur stimmen. Einzeln geprüft können beide Signaturen gültig sein. Der gefährliche Befund liegt zwischen ihnen: Zwei verschiedene Nachrichten verwendeten denselben OTS-Schlüssel.

RFC 9802 erklärt, dass zwei solche Signaturen Fälschungen rechnerisch machbar machen können. Das im Juni 2025 als IETF-Standard veröffentlichte Dokument definiert OIDs, Kodierungen, Schlüssel- und Signaturformate sowie zulässige Key-Usage-Werte für HSS, XMSS und XMSSMT in der Internet-PKI. Der RFC-Editor-Eintrag und die IETF-Historie belegen diesen Umfang.

Eine Algorithmuskennung beantwortet, wie Bytes zu prüfen sind. Sie beantwortet nicht, wie viele Zustandskopien existierten oder welche davon einen Index verbrauchte.

Der private Schlüssel besitzt eine Zeitachse

Bei zustandslosen Verfahren gilt die Sicherung oft dem geheimen Material. Zustandsbehaftete Hash-Signaturen verlangen zusätzlich die unwiderrufliche Chronik der Einmalkomponenten.

RFC 8554 erlaubt einem privaten LM-OTS-Schlüssel höchstens eine Nachricht; HSS ordnet viele solcher Schlüssel hierarchisch. RFC 8391 definiert XMSS und XMSSMT mit WOTS+, Merkle-Bäumen und adressierten Komponenten. Ein Parametersatz kann ein sehr großes Budget liefern, doch es bleibt endlich und jede Position hat nur eine sichere Verwendung.

Wiederhergestellt werden müssen daher Schlüsselbytes, bestätigter Folgeindex, Reservierungen, freigegebene Signaturen, verbrannte Positionen und Wiederherstellungsepoche. Der Verlust des Geheimnisses stoppt das Signieren. Der Verlust der Chronik kann unsicheres Signieren fortsetzen lassen.

NIST SP 800-208 empfiehlt LMS/HSS und XMSS/XMSSMT unter Betriebsauflagen und in Hardware-Kryptomodulen. RFC 9802 übernimmt diese Disziplin: Signaturen oder Indizes sollen protokolliert, vor Freigabe geprüft, künftige Zustände reserviert und die Zahl der Vorgänge prüfbar gehalten werden. Bei Wiederverwendung sind neue Signaturen einzufrieren, alte Ausgaben erneut zu prüfen und gegebenenfalls der Schlüssel zu sperren.

Das sind Handlungen eines Kontrollsystems. Ein Zertifikat führt keine davon aus.

Redundanz ist nicht Kopieren

Bei zustandslosen Signaturen kann derselbe Schlüssel auf zwei geschützten Geräten Verfügbarkeit schaffen. Bei HSS oder XMSS werden zwei identische Zustände zu zwei Eigentümern derselben Zukunft. RFC 9802 warnt, dass übliche Kopier- und Restore-Methoden mit hoher Wahrscheinlichkeit OTS-Wiederverwendung erzeugen, wenn sie den Zustand nicht korrekt erhalten.

Ein Rollback öffnet nach dem Abbild verbrauchte Positionen. Parallelbetrieb lässt zwei Geräte vom selben Punkt laufen. Eine verlorene Antwort schafft eine dritte Gefahr: Das Gerät schreibt den neuen Zustand und erzeugt die Signatur, doch die Steuerung erhält die Antwort nicht und wiederholt den Auftrag anderswo. Fehlende Zustellung macht den Index nicht unverbraucht.

Sichere Verfügbarkeit kann eine einzige Zustandsautorität, unumkehrbar getrennte Bereiche, eingezäunte Leases, monotone Hardwarezähler oder eine Wiederanlaufzeremonie verwenden, die den ersten neuen Index oberhalb aller historischen Reservierungen nachweist. Die konkrete Architektur ist lokal; das Verbot des Rückwärtslaufens ist gemeinsam.

Was X.509 nicht sehen kann

RFC 5280 definiert Zertifizierungspfade, Einschränkungen, Verwendungszwecke und Sperrlisten. RFC 9802 macht die neuen Algorithmen darin lesbar. Eine erfolgreiche Prüfung zeigt, dass die vorgelegte Signatur zum vorgelegten Schlüssel und Algorithmus passt.

Sie zeigt keine Parallelgeräte, Speicherabbilder, aufgegebenen Reservierungen, unveröffentlichten Signaturen oder Restore-Versuche. Auch das verbleibende Budget über die Zertifikatslaufzeit bleibt unsichtbar. Solange die Signatur des zweiten Zweigs den Prüfer nicht erreicht, unterscheidet dessen grünes Ergebnis keinen intakten Verlauf von einer Verzweigung.

Zu trennen sind: parsbares Format, gültige Signatur, akzeptierter Pfad und Sperrstatus, einmalige Reservierung, dauerhafter Verbrauch, Ausschluss einer zweiten Kopie, Abgleich aller Freigaben und Anwendungsergebnis. X.509 trägt vor allem die ersten Ebenen. Der Betreiber trägt den Zustandsnachweis; die Anwendung trägt den Ausgang.

Lu Hengs Running-Code Primacy ordnet die Rollen: Die OID koordiniert Interoperabilität, der einmalige Verbrauch muss in laufenden Systemen wahr bleiben. Das Prinzip von minimaler Anfangsspezifikation und lokaler Zukunftsentscheidung trennt gemeinsame Syntax von lokaler Zustands- und Restore-Verantwortung. Die Idee einer Realitätsschicht verhindert, dass die saubere Zertifikatsoberfläche die Maschinenhistorie ersetzt.

Quellen