Zusammenfassung

  • Der Working Group Last Call für draft-ietf-openpgp-nist-bp-comp-04 war bis 9. September 2026 angesetzt. Der Text ist weiterhin ein aktiver Internet-Draft mit angestrebtem Status Informational; der Termin belegt weder Annahme noch IETF-Freigabe.
  • Revision 04 führt die experimentellen Kennungen 100–107. Vorschlag, Editorenzweig und Implementierungstests verwenden bereits 37–44, während das erfasste IANA-Register 37–99 noch als nicht zugewiesen ausweist.
  • Bei den zusammengesetzten KEMs fließt die Nummer als algId in multiKeyCombine ein. Eine Umnummerierung verändert den abgeleiteten Schlüssel und das verpackte Sitzungsschlüsselmaterial; bei Signaturen ändern sich Pakete und Fingerprints.
  • Zu jedem Interoperabilitätsergebnis gehört ein Zustandsbeleg mit Dokumentfassung, exakter Nummer, Commit, Vektor-Hash, Build, Registerstand und Freigabefähigkeit.

Der Last-Call-Aufruf begann am 19. August und setzte den 9. September als Frist. Eine Frist beendet eine Kommentierungsphase, nicht automatisch die Debatte. Der erfasste Datatracker-Eintrag zeigt weiterhin In WG Last Call, beim IESG lediglich I-D Exists. Die Dokumenthistorie belegt Verfahrensschritte; ein Shepherd, verantwortlicher Area Director oder Telechat ist im erfassten Stand nicht ausgewiesen. Ziel ist Informational, nicht bereits ein RFC.

Revision 04 kombiniert NIST-Verfahren für die postquantenfeste Kryptografie mit etablierten elliptischen Kurven für OpenPGP. Sie beschreibt vier zusammengesetzte KEM- und vier Signaturalgorithmen, sämtlich optional. Die Nummern 100 bis 107 liegen im privaten oder experimentellen Bereich. Der Entwurf beschränkt sie auf unveröffentlichte Software und Interoperabilitätsexperimente, untersagt formelle Releases mit diesen Werten und kündigt eine IANA-Vorlage erst an, wenn alle aufgeführten Verfahren nicht-experimentelle Kennungen besitzen.

Die nächste Fassung läuft schon im Labor

Ein Vorschlag aus der Arbeitsgruppe ordnet die acht Verfahren den Werten 37 bis 44 zu. Daniel Kahn Gillmor bezeichnet die Anordnung in seiner Antwort als plausibel, rät Implementierern aber, die experimentellen Kennungen weiterzuverwenden, bis ein veröffentlichter Entwurf nicht-experimentelle Werte enthält. So lässt sich der kommende Zustand prüfen, ohne ihn zum geltenden Zustand zu erklären.

GitHub Pull Request 50 bildet diesen Vorlauf ab. Zum Erfassungszeitpunkt war er offen, nicht als Draft markiert und nicht gemergt. Der Head-Commit 577adce5255e7382e5d4b0c9e52be626deb77126 ersetzt 100–107 durch 37–44 und erzeugt Fingerprints, KEM-Ausgaben und Testvektoren in 27 Dateien neu.

In der Kommunikation ist der künftige Zustand bereits näher gerückt. Eine Nachricht der Autoren beschreibt Vektoren mit als „assigned“ bezeichneten Codepoints. Ein Bericht über rPGP meldet die Umstellung auf 37–44 und Übereinstimmung mit den NIST-Vektoren; die Interoperabilitätssuite soll jedoch auf die Bestätigung warten. Der GitLab Merge Request 255 hält diese Grenze fest: offen, Draft, nicht gemergt, mit dem Hinweis, vor der offiziellen Zuweisung nicht zu mergen.

Aus der Kennung wird ein Schlüsselinput

Beim zusammengesetzten KEM liest die Implementierung die Public-Key-Algorithmuskennung aus dem Schlüsselpaket und übergibt sie als algId an multiKeyCombine. Daraus entsteht der Schlüssel, der das Sitzungsschlüsselmaterial verpackt. Verwendet eine Seite 100 und die andere 37, unterscheiden sich die Eingaben und damit die abgeleiteten Werte – selbst wenn ML-KEM- und ECDH-Komponenten ansonsten gleich sind.

Auch bei den Signaturkombinationen steht die Kennung im OpenPGP-Schlüsselpaket. Ihre Änderung verändert die serialisierten Bytes und damit Fingerprints und weitere reproduzierbare Artefakte. Die mathematischen Definitionen von ML-KEM, ECDH und den Signaturprimitiven werden durch die Umnummerierung nicht verändert. Sie belegt weder mehr Sicherheit noch eine Schwachstelle. Verändert wird ihre Einbindung in OpenPGP, weshalb neue Vektoren technisch notwendig sind.

Das Register zeigt noch einen anderen Zeitpunkt

Das erfasste IANA-Register für OpenPGP trägt den Aktualisierungsstand 2. Juli 2026. Die Werte 35 und 36 sind RFC 9980 zugeordnet; 37–99 sind Unassigned, 100–110 Private or Experimental Use. „Assigned“ in einer Entwicklermeldung bezeichnet damit zu diesem Zeitpunkt eine erwartete oder branchbezogene Lage, nicht den öffentlichen Registereintrag.

RFC 9580 liefert den aktuellen OpenPGP-Paket- und Registerrahmen. RFC 8126 erklärt die Begriffe der Zuweisungspolitik. Ein IANA-Eintrag ist keine Sicherheitszertifizierung, keine Einführungspflicht und keine Produktfreigabe. Umgekehrt macht ein unzugewiesener Platz einen Laborversuch nicht wertlos. Der Versuch muss nur präzise benennen, welchen Zustand er geprüft hat.

Dafür genügt ein Algorithmus-Zustandsbeleg. Er nennt Dokumentrevision und Verfahrensstatus, experimentelle Nummer im veröffentlichten Text, vorgeschlagene Nummer im Zweig, PR/MR-Zustand und Commit, beobachtete IANA-Zeile samt Zeitpunkt, Vektor-Commit und Hash, Implementierungs-Build, tatsächlich ausgeführte Nummer sowie die Zulässigkeit eines formellen Releases. Alte 100er-Vektoren bleiben dann Belege für den früheren Experimentzustand; neue 37er-Vektoren können die nächste Fassung prüfen, ohne eine Registerentscheidung vorzutäuschen.

Quellen