Zusammenfassung

  • RFC 9964 führt den generischen Typ Algorithm Key Pair ein und registriert ML-DSA-44, ML-DSA-65 und ML-DSA-87 für JOSE und COSE, damit Schlüsselmaterial und Parameter einheitlich ausgedrückt werden.
  • Ein erforderliches alg, ein pub-Wert und eine gültige Prüfung regeln die kryptographische Form; sie bestimmen weder Schlüsselherkunft noch Vertrauensanker, Claim-Prüfung oder Freigabeentscheidung.

Technische Präzision wird leicht mit institutioneller Gewissheit verwechselt. Ein bekannter alg-Wert erlaubt einer Bibliothek, den passenden Verifikationsweg auszuwählen. Eine AKP-Struktur erlaubt ihr, öffentliche und private Bestandteile auseinanderzuhalten und Parameterprüfungen auszuführen. Diese Klarheit verhindert echte Interoperabilitätsfehler. Sie liefert aber keinen Beleg dafür, wer den Schlüssel in Umlauf gebracht hat, ob dessen Bindung an einen Aussteller stimmt oder weshalb eine Anwendung einer unterschriebenen Aussage folgen soll.

RFC 9964 konzentriert sich bewusst auf die ausdrückbare Seite dieses Problems. Michael Prorock und Orie Steele beschreiben darin ML-DSA-Schlüssel und -Signaturen für JOSE und COSE. Der Algorithm Key Pair, AKP, ist ein generisches Schlüsselmodell auch für Algorithmen, die nicht auf die Registrierungen des Dokuments beschränkt sind. Bei jedem AKP sind alg und pub erforderlich. priv enthält private Information und darf nicht in einem öffentlichen Schlüssel erscheinen. Das Standardwerk macht einen Schlüsseltyp zwischen Implementierungen lesbar und überprüfbar.

Die Vorgabe für private ML-DSA-Schlüssel ist ein gutes Beispiel. FIPS 204 kennt einen Seed und eine aus ihm expandierte private Schlüsselrepräsentation. RFC 9964 entscheidet sich ausschließlich für den Seed: priv muss ein 32 Byte langer Seed sein. Damit entsteht für JOSE und COSE eine kompakte gemeinsame Form. Das vereinfacht die Repräsentation, bescheinigt aber weder die sichere Erzeugung noch die Verwahrung des Seeds, den Weg des öffentlichen Schlüssels oder die Berechtigung, die mit ihm verbunden werden soll.

Auch die Registrierung von ML-DSA-44, ML-DSA-65 und ML-DSA-87 ist eine Koordinationsleistung, keine Vertrauensentscheidung. Sie legt fest, wie übereinstimmende Parameterwahlen in JOSE und COSE benannt werden. Sie wählt keinen Vertrauensanker, identifiziert keinen berechtigten Aussteller, prüft nicht die Bedeutung eines Claims und schaltet keine Handlung frei. Dafür braucht ein Relying Party eigene Belege über Schlüsselverteilung, Aussteller und Subjekt, Annahmeregeln und den Kontext der beabsichtigten Wirkung.

Das RFC nennt außerdem die großen Schlüssel und Signaturen von ML-DSA. Wo Bandbreite, Speicher oder Rechenleistung knapp sind, kann das Material ungeeignet sein. Diese Beobachtung trennt Laufzeit-Eignung von korrekter Kodierung und behauptet nichts über einen konkreten Einsatz. Die detaillierte Sicherheitsanalyse bleibt ausdrücklich außerhalb des Dokuments und verweist auf FIPS 204 sowie RFC 9881.

Prorocks Beitrag in dieser Co-Autorenschaft liegt somit in einer nützlichen Begrenzung: eine gemeinsame, strenge Ausdrucksform für ML-DSA-Material zu schaffen. Vertrauen bleibt eine verantwortliche Entscheidung außerhalb der Syntax — mit nachvollziehbarer Herkunft, klarer Ankerverwaltung, Claim-Politik und einer Person oder Stelle, die für die Folge einsteht.

Sources