Zusammenfassung

  • Revision 05 von draft-ietf-openpgp-nist-bp-comp erklärt, die experimentellen IDs 100–107 durch zugewiesene IDs 37–44 ersetzt zu haben. Das am 1. Oktober 2026 gesicherte IANA-Register zeigte 37–99 noch als unassigned. Belegt ist eine zeitliche Abweichung, nicht deren Ursache.
  • Alle Verfahren sind optional und an v6- oder neuere Schlüssel, Zertifikate und Signaturen gebunden. Erkennung einer ID ist kein Nachweis von Unterstützung oder korrekter Ausführung.
  • Bei Signaturen müssen ECDSA und ML-DSA bestehen. Beim KEM müssen ECDH und ML-KEM laufen; empfangene Kurvenpunkte sind vollständig zu validieren, bevor ein geheimer Skalar sie berührt.

Zuerst stimmt der Namensraum nicht überein

Der Text der Revision 05 dokumentiert die Umstellung von 100–107 auf 37–44. Fingerabdrücke, KEM-Zwischenwerte und Testvektoren wurden neu erzeugt; für alle vier Signaturvarianten kamen Detached-Signature-Vektoren hinzu. HTML und XML beschreiben dieselben Konstruktionen.

Das eingefrorene IANA OpenPGP Parameters Registry listete Verfahren bis 36 und markierte 37–99 als Unassigned. Daraus folgt weder eine Ablehnung noch ein Fehler des Entwurfs oder eine Aussage über einen bevorstehenden Update-Schritt. Nur die fehlende öffentliche Übereinstimmung an diesem Datum ist bewiesen.

Jeder Betriebsbeleg braucht deshalb Register-URL und Abrufzeit, Revision und Hash des Entwurfs, die ID im Objekt sowie Build und Konfiguration des interpretierenden Programms. Eine Datenbankzelle mit „43“ besitzt allein keine dauerhafte Semantik.

Auch der Dokumentstatus war vorläufig. Die Datatracker-Seite zeigte einen aktiven OpenPGP-WG-Entwurf vom 24. September 2026 mit Ablauf am 28. März 2027. Die API enthielt keinen intended RFC status, während der Kopf Informational sagte. Die Historie verlangte eine überarbeitete Fassung vor der Freigabe durch den WG-Vorsitz. Es handelte sich weder um einen RFC noch um einen verabschiedeten Standard.

Acht IDs teilen sich in acht optionale Profile

37 und 38 kombinieren ML-KEM-768/1024 mit ECDH auf NIST P-384/P-521. 39 und 40 verwenden brainpoolP384r1/P512r1. 41 bis 44 verbinden ML-DSA-65/87 mit ECDSA auf denselben Kurvenfamilien.

Jede Zeile ist ein MAY. Eine Bibliothek kann nur P-384 unterstützen, ein Produkt nur Signaturen aktivieren, eine Policy Brainpool ablehnen oder ein Keystore v6-Objekte zurückweisen. Die ID fixiert Komponenten und Längen, nicht den Rollout.

RFC 9580 liefert die moderne OpenPGP-Paket-, Schlüssel- und Signaturarchitektur. RFC 9980 definiert ML-KEM, ML-DSA und den hier verwendeten Mehrschlüssel-Kombinator. Der Entwurf beschränkt die Verfahren auf v6 oder neuer; Signaturen brauchen zudem einen Digest von mindestens 256 Bit. Der Parse-Beleg muss diese Bindungen enthalten.

Eine erfolgreiche Entschlüsselung ist ein später Beleg

Beim KEM führt der Sender ECDH und ML-KEM-Kapselung aus. Beide Geheimnisanteile, ECDH-Ciphertext, ECDH-Public-Key und Algorithmus-ID fließen in multiKeyCombine. Der resultierende KEK verpackt den Sitzungsschlüssel per AES-256 Key Wrap.

Der Empfänger muss PKESK-ID und lokale Secret-Key-ID vergleichen, komponentenspezifische Fixlängen parsen, beide Dekapselungen ausführen, den Kontext rekonstruieren und die 64-Bit-Integritätsprüfung des Unwraps bestehen. Bei v3 PKESK steht der symmetrische Algorithmus außerhalb der verpackten Daten; deshalb muss auch die Länge des ausgepackten Schlüssels passen.

FIPS 203 normiert ML-KEM; SP 800-56A Rev. 3 bildet den Kontext klassischer EC-Schlüsselvereinbarung. Ein positives Unwrap-Ergebnis kann nicht rückwirkend bezeugen, welche Prüfungen der Parser oder Provider zuvor tatsächlich ausgeführt hat.

Formatprüfung und Punktprüfung sind verschiedene Grenzen

Revision 04 verlangte die vollständige Prüfung empfangener Punkte auf den verwendeten Short-Weierstrass-Kurven. Vor einer geheimen Skalarmultiplikation muss feststehen: Der Punkt ist nicht der Unendlichkeitspunkt, seine Koordinaten liegen im Körper, und er erfüllt die Kurvengleichung.

Bei der Kapselung betrifft dies den ECDH-Public-Key des Empfängers; bei der Dekapselung den ephemeren ECDH-Ciphertext-Punkt. Jeder Fehler führt zum Abbruch. Der Entwurf warnt, dass die Multiplikation eines angreifergesteuerten Off-Curve-Punkts Invalid-Curve-Angriffe und die Wiedergewinnung des ECDH-Geheimnisses ermöglichen kann.

Die Grundlagen stehen in FIPS 186-5, den Kurven aus SP 800-186, den Brainpool-Kurven in RFC 5639 und der Public-Key-Validierung von SEC 1 v2. Ein exakt langes Bytefeld erfüllt keine Kurvengleichung von selbst. Die Telemetrie sollte Kurve, Validator-Build und Teilurteile ausweisen, ohne Geheimnisse zu protokollieren.

Composite Signature bedeutet logisches UND

Die Signatur enthält ECDSA und ML-DSA über den OpenPGP-Digest. Beide müssen gültig sein. Ein nicht unterstützter, übersprungener, fehlerhafter oder ungültiger Bestandteil macht die Komposition ungültig.

Die ECDSA-Längen für R und S hängen von der Kurve ab. ML-DSA-65 belegt 3.309 Oktette, ML-DSA-87 4.627. Digests unter 256 Bit sind abzulehnen. FIPS 204 definiert ML-DSA; RFC 9794 strukturiert die Terminologie traditionell/postquanten-hybrider Verfahren. Keines erlaubt ein OR der Einzelurteile.

Die neuen Detached-Signature-Vektoren prüfen Kodierung und Rechenweg eines Beispiels. Sie belegen weder Identität noch Berechtigung des realen Signers, Key-Provenienz oder Applikationsergebnis. Digest, ECDSA-Urteil, ML-DSA-Urteil, Composite-AND, Schlüsselvertrauen und Policy-Entscheid gehören in getrennte Felder.

Keine Aussage über einen Hersteller

Die Quellen belegen keine konkrete Implementierung, Produktion, Interoperabilität, Paketbeobachtung, Attacke, Störung, Leistung oder Adoption. Der Entwurf kann sich ändern, das Register kann aktualisiert werden, und Produkte können beliebige Teilmengen umsetzen. Ebenso bleibt die getrennte RFC-9980-Frage zu mehreren Empfängerpfaden außerhalb dieses Artikels.

Die belastbare Aussage ist enger: Für eine einzelne NIST/Brainpool-Komposition reichen ID und Format nicht. Ihr Betriebsbeweis führt vom autoritativen Namensraum über den vollständigen Parser bis zu zwei Komponentenurteilen und einer separaten Policy.