Zusammenfassung

  • Der IESG genehmigte draft-ietf-jose-hpke-encrypt-22 am 24. September 2026 zur Veröffentlichung als Proposed Standard. Das Dokument ist weiterhin ein Internet-Draft, noch kein RFC und kein Nachweis einer Implementierung.
  • Integrated Encryption verschlüsselt Klartext mit HPKE direkt für genau einen Empfänger. Key Encryption schützt dagegen einen gemeinsamen Content Encryption Key und kann HPKE-, ECDH- und RSA-Empfänger in einem JWE-JSON-Objekt verbinden.
  • Mindestens ein Empfänger muss validieren. Ob einer reicht oder alle erfolgreich sein müssen, entscheidet die Anwendung. Die Sicherheit des gemeinsamen CEK wird zudem vom schwächsten Empfängeralgorithmus begrenzt.

Der Klartext ist da, die Pflicht ist offen

Ein Unternehmen adressiert ein JWE an den Produktionsdienst, ein Aufbewahrungssystem und die Notfallwiederherstellung. Der Produktionspfad öffnet den CEK, die Inhaltsauthentisierung stimmt, die Bibliothek liefert Klartext. Dieser kryptografische Erfolg ist echt.

Trotzdem kann der Wiederherstellungspfad nach einem fehlerhaften Schlüsselwechsel ausgefallen sein. Das Archiv kann einen inzwischen untersagten Algorithmus verwenden. Vielleicht enthält der Umschlag einen Empfänger, der nie genehmigt wurde. Aus dem Klartext geht weder die Soll-Liste noch die Bedeutung eines einzelnen Erfolgs hervor.

Die IESG-Entscheidung vom 24. September macht diese Trennung aktuell. Revision 22 der JOSE-Arbeit zu HPKE mit JWE wurde zur Veröffentlichung als Proposed Standard genehmigt. Das ist ein belastbarer Prozessschritt, aber keine Produktfreigabe, kein Testvektorbericht, kein Schlüssel-Audit und kein Beleg für eine angewandte Verteilungsregel. Bis zum Abschluss des RFC-Editor-Prozesses bleibt der Text außerdem ein Internet-Draft.

Zwei Modi hinterlassen unterschiedliche Belege

Integrated Encryption wendet HPKE direkt auf den Klartext an. Ein eigener CEK existiert nicht; daher darf enc nicht vorkommen. Im geschützten Header wählt alg eine vollständig spezifizierte HPKE-Suite, ek ist verboten und es muss genau einen Empfänger geben. Das JWE Encrypted Key enthält das HPKE Encapsulated Secret. Die JWE-Felder für Initialisierungsvektor und Authentication Tag bleiben leer, weil diese Funktionen innerhalb von HPKE liegen.

Key Encryption fügt eine zweite Ebene ein. Ein zufälliger CEK verschlüsselt den Inhalt gemäß enc; anschließend verschlüsselt HPKE diesen CEK für den jeweiligen HPKE-Empfänger. Dessen JWE Encrypted Key enthält den HPKE-Ciphertext des CEK, während ek das Encapsulated Secret trägt. Die Recipient_structure bindet JOSE-Kontext, Inhaltsalgorithmus und optionale Anwendungsinformation über den HPKE-info-Wert an die Schlüsselableitung.

Dadurch werden mehrere Empfänger möglich. In der JWE JSON Serialization kann ein HPKE-Empfänger neben ECDH-ES+A128KW oder RSA-OAEP-256 stehen. Der Inhalt wird einmal verschlüsselt; jeder Empfänger erhält einen eigenen geschützten Weg zum selben CEK.

Das erleichtert gestaffelte Migrationen, Archivierung und Recovery. Zugleich wird die gesamte Empfängermenge zur Sicherheitsoberfläche.

„Mindestens einer“ ist nur die Protokolluntergrenze

Das Entschlüsselungsverfahren von Revision 22 weist die eigentliche Entscheidung ausdrücklich der Anwendung zu. Je nach Kontext kann ein erfolgreicher Empfänger reichen oder es können alle vorgeschriebenen Empfänger erforderlich sein. Das gemeinsame Minimum lautet nur: Scheitern alle, ist das JWE ungültig.

Bei JWE JSON soll die Verarbeitung außerdem an die Anwendung zurückmelden, welche Empfänger erfolgreich waren und welche scheiterten. Dieser Ergebnisvektor ist die Grundlage der lokalen Abnahmeregel.

Nehmen wir an, A gelingt mit HPKE, B scheitert wegen eines veralteten Schlüssels und C gelingt über einen Legacy-Algorithmus. Die Bibliothek kann Klartext liefern. Eine Regel, die nur A verlangt, darf akzeptieren. Eine Regel, die A und B verlangt, muss ablehnen. Eine dritte Regel kann wegen des Algorithmus von C ablehnen, obwohl C den CEK öffnen konnte. Dieselben Bytes erfüllen nicht automatisch dieselbe Pflicht.

Der Entwurf sagt zusätzlich: Sind die verwendeten Algorithmen im Anwendungskontext nicht akzeptabel, sollte die Anwendung das JWE trotz erfolgreicher Entschlüsselung als ungültig behandeln. Der Standard stellt interoperable Beobachtungen bereit; die Risikoverantwortung bleibt lokal.

Der schwächste Pfad erreicht denselben CEK

Alle Key-Encryption-Empfänger führen zum gemeinsamen CEK. Jeder erlaubte Pfad, der ihn gewinnt, kann den gemeinsamen Inhalt entschlüsseln. Die Security Considerations formulieren deshalb die Konsequenz: Bei mehreren Empfängern wird die Inhaltssicherheit durch den schwächsten Algorithmus begrenzt, mit dem der CEK verschlüsselt wurde.

Das macht gemischte Migrationen nicht pauschal unzulässig. Es verhindert jedoch, den Umschlag allein nach dem modernsten Pfad zu bewerten. Ein starker HPKE-Zweig verbessert keinen schwächeren, weiterhin zugelassenen Zugang zum selben Schlüssel.

Die Entstehung von Revision 22 zeigt, warum die Modusangabe zählt. Ein zweiter JOSE Working Group Last Call behandelte gezielt die Entfernung von HPKE-4-KE und HPKE-6-KE. Diese Key-Encryption-Kennungen fehlen in Revision 22, während HPKE-4 und HPKE-6 für Integrated Encryption erhalten bleiben. Ein Inventareintrag „HPKE unterstützt“ verschweigt genau die geänderte Grenze.

Der Entwurf rät ferner davon ab, dasselbe KEM-Schlüsselpaar parallel über mehrere HPKE-Modi oder -Suites zu verwenden oder einen Schlüssel zwischen HPKE- und Nicht-HPKE-Algorithmen zu teilen. Für einen Auditbeleg müssen Empfänger, Modus, Suite, Schlüsselidentität und erlaubter Zweck zusammenbleiben.

Heng Lus Trennung von Realitäts- und Symbolschichten ordnet die Befunde. Die IESG-Genehmigung ist ein institutioneller Fakt. alg ist ein Formatfakt. Der erfolgreiche Empfänger ist ein kryptografischer Fakt. Soll-Liste und Quantor „einer oder alle“ sind Kontrollfakten. Der beobachtete Anwendungsentscheid ist eine eigene Betriebstatsache.

Quellen