Zusammenfassung

  • AKP aus RFC 9964 macht alg und pub verpflichtend und trennt privates Material, damit ML-DSA in JOSE und COSE einheitlich abbildbar ist.
  • priv enthält nur den 32-Byte-Seed. Seed und expandierter privater Schlüssel ermöglichen nach Preisgabe beide Fälschungen und verlangen denselben Schutz.
  • Ein öffentlicher Fingerabdruck vergleicht Schlüssel und Algorithmus. Signaturbefugnis, Rotation und die Annahme eines Effekts durch einen Dienst gehören nicht in diesen Vergleich.

Vergleichbarkeit ist kein Mandat

JOSE und COSE brauchen für ML-DSA eine gemeinsame Schlüsselbeschreibung. RFC 9964 liefert AKP und registriert ML-DSA-44, ML-DSA-65 und ML-DSA-87. alg und pub sind erforderlich, priv darf in einem öffentlichen Schlüssel nicht vorkommen. Der Fingerabdruck beruht auf öffentlichen Elementen wie kty, alg und pub; Implementierungen können deshalb feststellen, ob zwei Darstellungen denselben öffentlichen Schlüssel unter demselben Algorithmus meinen.

Das ist Interoperabilität, nicht Machtzuweisung. Im Fingerabdruck stehen weder Seed noch Organisation noch Genehmigungsweg. Ein öffentliches Verzeichnis kann einen Fingerabdruck zur Prüfung anbieten. Daraus wird nicht das Recht, privates Material zu verwahren, einen Signaturvorgang freizugeben oder eine empfangende Anwendung zur Wirkung zu verpflichten.

FIPS 204 lässt privates Material als Seed oder als expandierten Schlüssel zu. RFC 9964 entscheidet sich ausschließlich für den Seed, um beiden Ökosystemen eine kompakte, einzige Darstellung zu geben. Zugleich verlangt der Standard für beide Formen den gleichen Schutz: Wer eine der beiden unbefugt erlangt, kann Signaturen erzeugen. Die Festlegung beseitigt eine Serialisierungsmehrdeutigkeit, nicht die Fragen nach Sicherungskopien, Wiederherstellung, Delegation, Gerätegrenzen und personeller Verantwortung.

Eine belastbare Kette führt daher getrennte Nachweise. AKP und öffentlicher Fingerabdruck sind Schlüsselnachweis. Ort und Schutz des Seed sind Verwahrnachweis. Gegenstand und Reichweite einer Signaturanfrage sind Vorgangsnachweis. Der Freigebende liefert den Autorisierungsnachweis. Die Prüfung und Annahme oder Ablehnung beim Empfänger ist Dienstnachweis. Diese Nachweise können zusammenhängen, aber keiner macht den nächsten entbehrlich. Ein korrekter Schlüssel kann für einen Auftrag gesperrt sein; eine gültige Signatur kann an einer Dienstregel scheitern.

Größere Signaturen schaffen keine größere Zentrale

ML-DSA hat handfeste Größenfolgen. Öffentliche Schlüssel und Signaturen sind deutlich größer als viele herkömmliche Alternativen, und JSON-Kodierung vergrößert sie weiter. RFC 9964 weist darauf hin, dass Umgebungen mit engen Netz-, Speicher- oder Rechengrenzen ungeeignet sein können. Daraus folgt keine Ermächtigung, ein zentrales Profil überall durchzusetzen. Beteiligte können ihre eigene Strecke vermessen, geeignete Parameter wählen, ungeeignete ablehnen und während der Erprobung einen Ausweichweg erhalten.

Auch die Veröffentlichung eines Standards beweist keine Annahme. Ein Baustein kann eine Signatur prüfen, ohne dass alle abhängigen Systeme Größe, Algorithmus und Zweck akzeptieren. Heng Lus Prinzip belässt Form, Validierung und Vergleich als überprüfbaren gemeinsamen Kern; Verwahrung, Freigabe, Annahme und Ausstieg bleiben freiwillige lokale Entscheidungen derjenigen, die das Risiko tragen.

Der Prüfpfad muss mehr als „Signatur gültig“ sagen können: Wie wurde der öffentliche Schlüssel bestimmt? Welche Grenze schützte das private Material? Was sollte der Auftrag bewirken? Wer gab ihn wann frei? Welche zusätzliche Regel prüfte der Empfänger? Wie werden künftige Verwendungen gestoppt, wenn sich die Freigabe als falsch erweist? Ohne diese getrennten Antworten wird Kryptografie zum Ersatzwort für Steuerung.