Summary

  • Ein mit einer Pure-OID gekennzeichneter SLH-DSA-Schlüssel darf nach RFC 9909 keine HashSLH-DSA-Signatur erzeugen oder prüfen; umgekehrt gilt dasselbe.
  • Der belastbare Beleg umfasst fehlende AlgorithmIdentifier-Parameter, rohe Schlüsselbytes, zulässige keyUsage-Bits sowie getrennte Ergebnisse für Signatur, Zertifizierungspfad und Anwendungspolitik.

Der HSM-Test war grün. Der Algorithmus stand in der Funktionsliste, ein Schlüssel ließ sich erzeugen, und der Anbieter sprach von Post-Quantum-Fähigkeit. Erst bei der Ausstellung zeigte sich die unbeantwortete Frage: Sollte das CA-Zertifikat Pure SLH-DSA oder HashSLH-DSA festschreiben?

Das ist ein konstruiertes Prüfszenario, kein Vorfall. RFC 9909 macht jedoch deutlich, dass die Wahl nicht nachträglich beliebig ist. Trägt der öffentliche Schlüssel eine Pure-OID, darf eine HashSLH-DSA-Signatur nicht damit verifiziert werden. Enthält AlgorithmIdentifier ein NULL, obwohl parameters fehlen muss, ist auch ein passender Name nicht profilkonform.

Der IETF veröffentlichte RFC 9909 im Dezember 2025 als Standards-Track-Dokument der LAMPS-Arbeitsgruppe. Es definiert SLH-DSA für X.509-Zertifikate, Sperrlisten sowie öffentliche und private Schlüssel. Grundlage ist der NIST FIPS 205. SPHINCS+ war die frühere Bezeichnung; der RFC warnt ausdrücklich, dass SPHINCS+ und SLH-DSA nicht kompatibel sind.

Zwölf OIDs gehören zu Pure, zwölf zu HashSLH-DSA. Sie unterscheiden 128, 192 und 256 Bit Sicherheitsniveau, small und fast sowie SHA-2 und SHAKE. Bei HashSLH-DSA ist auch die Pre-Hash-Funktion Teil der Kennung. Das NIST CSOR führt dieselben Zuweisungen.

Entscheidend ist die Mehrfachrolle der OID: Sie identifiziert öffentlichen Schlüssel, privaten Schlüssel und Signaturalgorithmus. Damit verbietet der Standard eine mathematisch vielleicht mögliche, semantisch aber mehrdeutige Querbenutzung zwischen Pure und Hash. Eine Bibliothek darf diese Grenze lokal lockern; sie darf das Ergebnis dann nicht als allgemeine Interoperabilität ausgeben.

parameters muss bei allen erfassten Kennungen abwesend sein. Ein DER-kodiertes NULL ist nicht abwesend. Andere Algorithmusprofile haben über Jahrzehnte unterschiedliche Gewohnheiten erzeugt. Ein Generator kann daher NULL beifügen und ein großzügiger Parser es hinnehmen. Erst der Original-DER-Beleg zeigt, ob der gemeinsame Vertrag oder nur eine lokale Ausnahme ausgeführt wurde.

Der öffentliche Schlüssel besteht aus PK.seed || PK.root, insgesamt 2*n Byte bei n gleich 16, 24 oder 32. SubjectPublicKeyInfo trägt diese Rohbytes direkt im BIT STRING, ohne zusätzliche ASN.1-Hülle. Der private Schlüssel ist SK.seed || SK.prf || PK.seed || PK.root, also 4*n Byte, im privateKey-OCTET-STRING von OneAsymmetricKey.

OneAsymmetricKey kann den öffentlichen Schlüssel zusätzlich aufnehmen. Das stärkt eine Konsistenzprüfung, doch manche Importfunktionen akzeptieren diese Form laut RFC nicht. Größere Prüfbarkeit und größte Importbreite sind daher getrennte Ziele. Entscheidend ist der gemessene Weg durch Erzeugung, Export, Sicherung, Wiederherstellung und HSM.

Ist keyUsage vorhanden, muss mindestens digitalSignature, nonRepudiation, keyCertSign oder cRLSign gesetzt sein. keyEncipherment, dataEncipherment, keyAgreement, encipherOnly und decipherOnly sind ausgeschlossen. SLH-DSA signiert; es führt keinen Schlüsselaustausch aus. Danach bleiben die Pfad-, Namens-, Gültigkeits- und Sperrregeln aus RFC 5280 offen.

Pure verarbeitet die vorbereitete Nachricht, HashSLH-DSA reduziert sie durch einen definierten Pre-Hash. Das ist für externe Signaturmodule relevant: SLH-DSA verarbeitet die interne Nachricht zweimal und muss sie im Speicher halten. Große CRLs oder Zertifikate mit vielen SANs können im Pure-Modus eine Übertragungs- oder Speichergrenze des HSM erreichen.

Auch der Prüfer braucht bei Zertifikaten und CRLs das vollständige Objekt. Ein Zufallswert aus der Signatur fließt vor der Nachricht in den Digest, die X.509-Reihenfolge stellt die Signatur jedoch dahinter. Eine einfache Einpass-Verarbeitung entsteht dadurch nicht. Hash verkleinert M', beweist aber keine Kompatibilität eines bestimmten Produkts.

RFC 9814 zeigt die Anwendungsgrenze. Für CMS SignedData spezifiziert es Pure und kann signed attributes verwenden, um dem Gerät einen kleineren Wert zuzuführen. Diese Regel darf nicht als Leistungsbeleg für Zertifikate und CRLs übernommen werden. Derselbe Algorithmus besitzt je Anwendung einen anderen Ausführungsvertrag.

Stateless hebt Lebensdauer nicht auf. Ein Baum darf nicht mehr als 2^64 Signaturen erzeugen. Wo diese Größenordnung erreichbar wäre, sind Zähler, ein früheres Vernichtungsziel oder ein begrenztes Not-After nötig. Unabhängige Schlüsselerzeugung, Zufall, Verwahrung, Fehler- und Seitenkanalschutz bleiben Pflichten.

Zum Stichtag führte die offizielle Errata-Seite zwei Einträge, beide Reported, nicht Verified. Eine Meldung ist kein angenommener Normtext. Meldung, Prüfung, Dokumentänderung und Softwareänderung brauchen eigene Zeitstempel.

Ein Betriebsbeleg hält Original-DER und Hash, Schlüssel- und Signatur-OID, parameter-Status, Längen, Hüllen, keyUsage, leeren Kontext, Aussteller, Subjekt, Trust Anchors, Sperrinformationen sowie Validator- und Provider-Build fest. Danach folgen vier getrennte Urteile: Format, Signatur, Pfad, Anwendung. Ein Fallback ist eine andere Ausführung.

Heng Lus Running-Code Primacy verlangt diese beobachtbare Kette. Minimum Initial Specification begrenzt den gemeinsamen Teil auf testbare Interoperabilität. Reality Layers verhindert, dass eine registrierte Kennung Vertrauen oder Befugnis simuliert.

RFC 9909 zertifiziert keine post-quantum-fähige Flotte. Es trennt die Arbeit: OID koordiniert, DER materialisiert, Parser erkennt, Profil prüft, Kryptografie verifiziert, Pfad vertraut, Anwendung entscheidet. Der grüne HSM-Test war ein Anfang, nicht das Ergebnis.

Sources