Zusammenfassung

  • draft-ietf-hpke-hpke-05 befindet sich in der IESG Evaluation, definiert Base 0x00 und PSK 0x01 und reserviert 0x02 sowie 0x03, die RFC 9180 für Auth und AuthPSK verwendete.
  • Eine Spezifikation kann den nächsten gemeinsamen Kern festlegen. Ob alter Code, Konfigurationen, gespeicherte Objekte und Partner diesen Kern erreicht haben, muss der Betrieb separat beweisen.

Quellcode, Paket, Prozess und Nachricht haben verschiedene Lebenszeiten. Ein Funktionsname kann aus dem neuesten Repository verschwinden, während ein statisch gelinktes Werkzeug, eine alte Appliance oder ein noch nicht neu gestarteter Prozess dieselbe Funktion weiterführt.

Genau deshalb ist die kürzere Modustabelle des HPKE-Nachfolgers ein Startsignal und kein Abschlussprotokoll. Sie sagt, was der künftige Kern enthalten soll. Sie kennt nicht den Zustand der Systeme, die RFC 9180 implementiert haben.

Der Text ist noch ein Internet-Draft

Datatracker führt Revision 05 vom 26. September 2026 als aktiven Entwurf der HPKE Working Group. Er zielt auf Proposed Standard, wurde zur Veröffentlichung eingereicht, befindet sich in der IESG Evaluation und steht auf der Telechat-Agenda vom 8. Oktober. Nach dem Versionswechsel ist erneut eine IANA-Prüfung nötig.

Im Kopf steht, der Entwurf würde RFC 9180 bei Genehmigung obsolet machen. Noch fehlt diese Genehmigung; der eingefrorene Belegsatz enthält weder eine abgeschlossene IESG-Entscheidung noch einen neuen RFC.

Auch die Entfernung der Modi stammt nicht erst aus Revision 05. Revision 04 vom Juli enthielt bereits dieselbe Tabelle und denselben Änderungspunkt. Aktuell ist der Verfahrensstand dieses Designs, nicht eine neue September-Erfindung.

RFC 9180 ist ein Informational RFC aus dem IRTF-Stream. Der Nachfolger strebt einen IETF Proposed Standard an. Das kann den nächsten Koordinationspunkt stärken, aber keinen Bestandsbericht über frühere Implementierungen ersetzen.

Rückwärtskompatibilität endet an der Schnittmenge

Anhang A verspricht identisches Verhalten dort, wo beide Dokumente dieselbe Funktion beschreiben. Base und PSK liegen in dieser Schnittmenge.

Auth und AuthPSK liegen außerhalb. RFC 9180 weist ihnen 0x02 und 0x03 zu und definiert Abläufe mit einem statischen Senderschlüssel. Revision 05 reserviert die Werte und entfernt die Varianten. Eine pauschale Aussage, der Nachfolger sei rückwärtskompatibel, verdeckt gerade den Teil, der nicht mehr dazugehört.

Ein übereinstimmender Base-Testvektor beweist Interoperabilität für Suite, Eingaben und Implementierungen dieses Tests. Er beweist nicht, dass alle Aufrufer eine neue API nutzen, alle Prozesse neu gestartet sind oder alle Archive ohne den alten Leser auskommen.

Jeder Kompatibilitätsbeleg sollte Dokumentversion, Modus, Suite, Build, API-Einstieg, Schlüsselrolle, Anwendungsprofil und Peer nennen. Ein grünes Feld „HPKE“ ist für eine Abschaltentscheidung zu grob.

Im Ciphertext steckt kein universelles Anlagenverzeichnis

HPKE wird von anderen Protokollen eingebettet. Der Entwurf überlässt der Anwendung den Transport nicht geheimer Parameter wie enc und psk_id. Besitzt ein Empfänger mehrere Schlüssel, muss die Anwendung auch den richtigen auswählen.

Modus und Ciphersuite kommen aus diesem Kontext. Es gibt kein einziges selbstbeschreibendes HPKE-Format, dessen sichtbarer Header in jedem Produkt einen vollständigen Moduszensus ermöglicht.

Ein Profil wählt eine API-Funktion, ein anderes bindet den Modus an eine Objektversion, ein drittes an Konfiguration oder Aushandlung. Eine Paketaufzeichnung kann Ciphertexte zählen, ohne den Setup-Pfad zu kennen. Eine Quelltextsuche kann Auth-Symbole finden, ohne ihre Aktivierung zu zeigen.

Auch ein negatives Suchergebnis braucht einen Nenner. Statische Links, vendored copies, Hardware, Recovery-Images, ruhende Worker und alte Container können außerhalb des untersuchten Repositories liegen.

Stilllegung braucht mehrere voneinander unabhängige Belege

Der Normbeleg nennt Revision und Prozessstand. Der Profilbeleg beschreibt die Moduswahl der Anwendung. Der Implementierungsbeleg identifiziert Paket, Build und tatsächlich geladenes Binärprogramm. Der Konfigurationsbeleg zeigt erlaubte Pfade pro Dienst, Operation und Partner.

Der Nutzungsbeleg beobachtet die wirkliche Auswahl. Der Bestandsbeleg erfasst Queues, Backups und Archive. Der Peer-Beleg testet das Ersatzprofil mit der vorgesehenen Gegenstelle. Der Ergebnisbeleg bestätigt die Anwendungswirkung nach der Kryptographie.

Ein Paketupdate ersetzt diese Kette nicht. Die neue Version kann installiert sein, während ein alter Prozess läuft. Ein Neustart kann eine Mandantenausnahme übernehmen. Eine geschlossene Ausnahme migriert keine gespeicherten Objekte. Ein erfolgreicher PSK-Canary umfasst nicht jeden seltenen Partner.

Umgekehrt beweist ein vorhandenes Auth-Symbol nur Fähigkeit, eine erlaubte Ausnahme nur Berechtigung und ein geöffnetes Altobjekt nur Entschlüsselung. Identität, Autorisierung, Frische und Geschäftsergebnis bleiben eigene Aussagen.

Der Individual Draft ist ein Abzweig, keine IETF-Entscheidung

draft-ms-hpke-auth-modes-01 schlägt vor, AuthPSK als strikte Erweiterung wiederherzustellen. Auth-Mechanik kehrt als Baustein zurück; ein eigenständiger Auth-Modus nicht, weil er keine quantenresistente Verschlüsselung liefert.

Datatracker kennzeichnet das Dokument ausdrücklich als individuellen Internet-Draft ohne IETF-Billigung und ohne formale Stellung im Standardsprozess. Es ist kein angenommener Migrationspfad.

Sein begrenzter Beweiswert ist dennoch nützlich: Aus dem gemeinsamen Kern entfernt heißt nicht technisch unbeschreibbar. Würde die Erweiterung vorankommen, bildete sie einen eigenen Kompatibilitätssatz mit eigener Analyse, Bindung, Implementierung und Adoption.

Diskussionen in HPKE- und JOSE-Listen dokumentieren Ansichten zu Signaturen, impliziter Authentisierung, Key Encryption und Post-Quantum-Kombinationen. Sie belegen eine Debatte, nicht Konsens, Verbreitung oder einen Sicherheitsvorfall.

PSK-Besitz ist noch keine Organisationsidentität

Der Kandidat schreibt dem PSK-Modus Senderauthentisierung im kryptografischen Sinn zu: Der Ersteller eines gültigen Kontexts besitzt den Pre-Shared Key.

Ein PSK kann einem Prozess, einem Cluster oder vielen Geräten bekannt sein. Verteilung, Umfang, Rotation und Bindung an eine Anwendungsidentität liegen außerhalb von HPKE. Besitz beweist nicht automatisch ein geschäftliches Mandat.

Der Entwurf nennt außerdem Nichtziele: kein anwendungsseitiger Replay- oder Downgrade-Schutz, keine Nachrichtenordnung oder Verlustbehandlung, keine Längenverschleierung, kein Schutz vor schlechter ephemerer Zufälligkeit und keine Forward Secrecy bei späterem Verlust des privaten Empfängerschlüssels.

Eine erfolgreiche PSK-Entschlüsselung genügt deshalb nicht als Migrationsabschluss. Die Anwendung muss Akteur, Autorität, Frische und erwartetes Ergebnis definieren und die Schlüsselbindung daran prüfen.

Das letzte gespeicherte Objekt bestimmt die Lebensdauer des Lesers

Neue Auth/AuthPSK-Produktion kann enden, lange bevor Backups, verzögerte Jobs, Wiederholungsqueues oder Archive ablaufen. Werden Schlüssel oder Decoder zu früh gelöscht, entsteht ein irreversibler Verfügbarkeitsverlust.

Bleibt der Altpfad dagegen unbegrenzt, ohne Isolation, Eigentümer und Ablaufdatum, wird eine Übergangsausnahme zur dauerhaften Angriffsfläche.

Das Bestandsregister sollte Format, Erstellungszeitraum, Profilversion, Schlüsselkennung, Aufbewahrungshorizont und letzten erfolgreichen Ersatzlesetest enthalten. Fehlen historische Metadaten zur sicheren Moduserkennung, ist diese Unsicherheit ein Befund und darf nicht aus der Form des Ciphertexts weginterpretiert werden.

Veröffentlichung setzt das Ziel, Messung bestätigt den Wechsel

Heng Lus Konzepte Minimum Initial Specification und Running-Code Primacy trennen Veröffentlichung von Adoption. Eine spätere Änderung wird für einen Teilnehmer durch Implementierung, Validierung, Bereitstellung und Nutzung real. Nichtadoption lässt einen anderen Kompatibilitätssatz zurück.

Das schwächt den Standard nicht. Der Entwurf kann den gemeinsamen HPKE-Kern verkleinern. Betreiber müssen anschließend mit lokalen, Peer- und Ergebnisbelegen zeigen, dass sie dort angekommen sind.

Ein belastbarer Abschluss nennt untersuchte Profile und Builds, geschlossene Ausnahmen, migrierte oder vernichtete Objekte, getestete Partner und den Beobachtungszeitraum ohne Altpfad. Außerhalb dieses Rahmens bleibt der Zustand unbekannt.

Quellen