Zusammenfassung

  • draft-ietf-cose-hpke-27 erlaubt, HPKE-Chiffretext außerhalb von COSE_Encrypt oder COSE_Encrypt0 zu transportieren; das interne Feld ist dann nil. Eine später auf das COSE-Objekt angewandte Signatur oder ein MAC deckt diese abgetrennten Bytes nicht ab.
  • Ein AEAD kann die Integrität des externen Chiffretexts sichern. Sein Tag ist dennoch kein Ersatz für eine äußere Absenderauthentisierung, eine Identitätsentscheidung, fachliche Autorisierung oder einen Wirkungsnachweis.
  • Revision 27 befand sich am 1. Oktober 2026 im IESG-Status AD Evaluation::AD Followup und war noch kein RFC. Drei Implementierungen validierten laut Shepherd Beispiele, nicht die Blob-Verwahrung eines konkreten Produkts.

Der gefährlichste Satz in einer Sicherheitsfreigabe kann technisch richtig sein: „Die Signatur ist gültig.“ Ohne Objekt dazu ist er fast wertlos. Er sagt nicht, ob ein extern gespeicherter Chiffretext, ein Mandantenkontext oder die ausgeführte Aktion Teil dieser Signatur war.

Revision 27 des COSE-HPKE-Entwurfs zieht die Grenze ausdrücklich. Wird abgetrennter Chiffretext mit COSE_Encrypt oder COSE_Encrypt0 verwendet, erfasst die nachfolgende Integritätssicherung durch COSE_Sign, COSE_Sign1, COSE_Mac oder COSE_Mac0 diesen Chiffretext nicht. Implementierungen müssen ihm eigene Integrität geben.

nil verlagert Daten, nicht Verantwortung

RFC 9052 definiert, dass COSE-Inhalt getrennt transportiert werden darf. Im Kontrollobjekt steht nil; die Anwendung liefert die Bytes separat. Das ist für große Artefakte, Firmware und Objektspeicher wirtschaftlich. Zugleich entsteht eine neue, beweispflichtige Verbindung.

Im integrierten Modus erzeugt HPKE ct. Der Text von Revision 27 erlaubt die direkte Ablage in COSE_Encrypt0 oder den getrennten Transport. Im Key-Encryption-Modus verschlüsselt Schicht 0 den Inhalt einmal mit einem CEK; Schicht 1 schützt diesen CEK für jeden Empfänger. Die XML-Quelle bildet dieselbe Architektur ab.

Ein veränderlicher Alias kann nun einen anderen Blob liefern, ohne den signierten Umschlag zu ändern. Gleiches gilt für überschreibbare Objektnamen, Range-Zusammenbau, transparente Kompression oder Wiederherstellung aus einem Backup. Deshalb gehören unveränderliche Version, Länge, Hash und Auflösungspfad des tatsächlich geprüften Chiffretexts zum Sicherheitsbeleg.

Eine Kette aus begrenzten Aussagen

Die äußere Signatur bestätigt die genaue Sig_structure; ein MAC bestätigt seine entsprechende Struktur unter einem gemeinsamen Schlüssel. Nicht übergebene Bytes werden nicht durch visuelle Nähe eingeschlossen.

Das AEAD der Schicht 0 kann den getrennten Chiffretext authentisieren. Bei korrektem CEK, Nonce und Associated Data erkennt ein gültiges Tag Veränderungen. Das ist eine starke Integritätsaussage unter einem symmetrischen Schlüssel, aber keine öffentliche Behauptung über die Person des Absenders.

HPKE Open liefert einen weiteren Nachweis: Die Kapselung konnte für einen Empfängerschlüssel verarbeitet werden. Danach folgen Schlüsselidentität, fachliche Autorisierung und tatsächlicher Commit.

Nachweis Belastbare Aussage Offene Frage
Äußere Signatur/MAC Abgedeckte Bytes sind unter dem Schlüssel gültig War der getrennte Blob Teil der Eingabe?
AEAD Chiffretext und AAD sind unter dem CEK integer Wer ist der öffentliche Absender?
HPKE Open Empfängerbezogene Verarbeitung gelingt Darf der Absender handeln?
Identität Schlüssel gehört zu akzeptiertem Principal Ist diese Operation gestattet?
Autorisierung Aktuelle Regel erlaubt die Operation Wurde sie ausgeführt?
Wirkung Externer Zustand hat sich geändert Ist er mit allen Nachweisen verbunden?

Der Empfängerkontext bindet die nächste Schicht

Recipient_structure nimmt den Algorithmus der unmittelbar unteren Schicht und geschützte Empfänger-Header in HPKE info auf. Damit wird der Mechanismus, der den CEK schützt, an den Inhaltsalgorithmus gebunden, der ihn nutzt.

Die Struktur muss nach RFC 8949 deterministisch kodiert werden. Sender und Empfänger bauen unabhängig eine nicht mitgesendete Eingabe. Unterschiedliche Serialisierungen gleicher Werte würden die Kryptografie scheitern lassen. Determinismus löst dieses Darstellungsproblem, aber weder Schlüsselbesitz noch Blob-Unveränderlichkeit oder Autorisierung.

recipient_extra_info kann Kontext binden, den beide Seiten außerhalb der Nachricht besitzen: Mandant, Sitzung, Kanal oder Zweck. Da der Wert nicht übertragen wird, brauchen Herkunft, Version und Verhalten bei Fehlen eigene Belege. Ein stiller Rückfall auf den Leerstring kann die beabsichtigte Trennung aufheben.

Das empfohlene kid unterstützt die Auswahl des statischen Empfängerschlüssels und kann als geschützter Header in den HPKE-Schlüsselplan eingehen. Es bleibt dennoch eine Kennung. Kurze Werte können in mehreren Namensräumen vorkommen; Caches können alte Schlüssel liefern; ein Recovery-Schlüssel kann entschlüsseln, ohne den erwarteten operativen Status zu besitzen.

Verschlüsselung zum Empfänger ist keine Absenderrolle

RFC 9180 schuf das bekannte HPKE-Modell. Der aktive Nachfolgeentwurf würde RFC 9180 bei Annahme ablösen, ist aber noch Arbeit im Gang. Ein Inventar muss Revision, Modus und Suite festhalten, nicht nur „HPKE“.

Der Base-Modus authentisiert den Absender nicht im KEM. COSE-Signatur oder MAC können Authentisierung ergänzen, sofern ihre Abdeckung stimmt. RFC 9338 trennt benachbart zwischen der Bestätigung verschlüsselter Daten und einer Aussage über Klartext. Wer die Bedeutung genehmigen will, muss genau diese Bedeutung kryptografisch erfassen.

RFC 9053, das IANA-COSE-Register und das IANA-HPKE-Register koordinieren Algorithmen und Codepunkte. Eine Registrierung bescheinigt weder sichere Produktkonfiguration noch Schlüsselrotation oder Berechtigungsprüfung.

Standardisierungsfortschritt ist kein Betriebsnachweis

Der Datatracker zeigte Revision 27 am 1. Oktober 2026 als COSE-WG-Dokument mit Ziel Proposed Standard, beim IESG eingereicht und in AD Evaluation::AD Followup. Die Historie datiert diese Revision auf den 12. September. Eine RFC-Nummer existierte nicht.

Der Shepherd-Bericht beschreibt breite Diskussion und drei unabhängige Implementierungen, die laut Autoren bei IETF 125 Beispiele validierten. Das ist nützliche Running-Code-Evidenz, aber kein Nachweis für unveränderliche Blobs, korrekten Zusatzkontext, Widerruf oder Autorisierung in einer bestimmten Installation.

Das Coverage-Manifest

Pro Entscheidung sind zu halten: vollständige COSE-Bytes; Typ und Tag; geschützte und ungeschützte Header; eingebetteter oder getrennter Zustand; unveränderlicher Locator, Länge und Hash des Chiffretexts; Hash der Signatur/MAC-Eingabe; AEAD-Algorithmus, AAD-Hash und Tag-Ergebnis; HPKE-Modus und Suite; Hashes von ek und Recipient_structure; Herkunft von recipient_extra_info; kid-Namensraum und Schlüsselversion; Open-Ergebnis; Klartext-Hash innerhalb der Vertrauensgrenze; Identitätsentscheidung; Autorisierung; Commit-ID; beobachtete Wirkung.

Private Schlüssel und unnötiger Klartext gehören nicht ins Log. Hashes, versionierte Referenzen und Entscheidungsbelege reichen. Auch Nichtabdeckung muss sichtbar bleiben: outer_signature_covers_blob=false kann mit gültigem AEAD sicher sein, darf aber nicht in ein pauschales signed=true umgedeutet werden.

Minimum Initial Specification legt ein kleines gemeinsames Manifest nahe. Running-Code Primacy fordert die realen API-Puffer. The Policy Mirror zeigt die Macht von Storage- und Schlüsselauflösungsdefaults. Reality Layers hält Syntax, Bytes, Nachweis, Identität, Erlaubnis und Wirkung auseinander.

Quellen