Zusammenfassung

  • RFC 9597 registriert COSE-Headerparameter 15 als Map für CWT-Claims, auch bei verschlüsseltem, abgetrenntem oder nicht als CWT codiertem Payload.
  • Ein früh sichtbarer Issuer kann die Suche nach einem Schlüssel lenken; Identität und Wirkung bleiben jedoch vorläufig, bis die kryptografische Verarbeitung das Ergebnis bestätigt.
  • Doppelte Claims in Header und CWT-Payload müssen normalerweise übereinstimmen. Übereinstimmung, Wahrheit, Schlüsselkompetenz, Datenschutz und Erlaubnis bleiben getrennt.

Der Empfänger kann den Payload noch nicht lesen. Im COSE-Header steht jedoch ein Issuer. Die Plattform wählt dessen Schlüsselverzeichnis, lädt Kandidaten und reserviert Ressourcen. Danach scheitert die Signatur.

Ob das System sicher gearbeitet hat, zeigt sich nicht nur am Reject. Entscheidend ist, ob der vorläufige Tenant, der Cache-Eintrag und die Audit-Identität verschwinden. Bleiben sie bestehen, hat der unbestätigte Claim bereits Realität erzeugt.

RFC 9597 standardisiert den nützlichen ersten Schritt. CWT-Claims können in Headern beliebiger COSE-Strukturen stehen, wenn der Payload verschlüsselt oder abgetrennt ist oder gar kein CWT und kein CBOR enthält. Früh verfügbar heißt dabei ausdrücklich nicht früh autorisiert.

Ein Container hält zwei Nummernräume auseinander

COSE-Headerparameter und CWT-Claims verwenden kompakte Ganzzahlen. Direkte Einträge würden die Zuweisungen beider Register vermischen. Deshalb führt das IANA-COSE-Register „CWT Claims“ unter Label 15. Der Wert ist eine Map mit Schlüsseln aus dem CWT-Register.

RFC 8392 beschreibt Issuer, Subject, Audience, Expiration, Not-Before, Issued-At und Token-ID. RFC 8610 liefert die CDDL-Notation. Register und Schema koordinieren Namen und Form, nicht die Annahmeregeln eines Endpoints.

Der Parameter ist nicht auf CWT-Payloads beschränkt. Auch ein Bild oder Firmware-Objekt kann signiert sein und einen Issuer für die Schlüsselsuche offenlegen. Die Map beweist daher nicht, was der Payload ist. Das lokale Profil muss Semantik und Folgen definieren.

Geschützt ist kleiner als vertrauenswürdig

RFC 9052 trennt geschützte und ungeschützte Header-Maps. RFC 9597 empfiehlt die geschützte Map, weil ungeschützte Claims veränderbar sind, und erlaubt den Parameter insgesamt nur einmal.

Ein Empfänger darf aus der Empfehlung keine Empfangsgarantie machen. Er braucht eine Regel für Label 15 im ungeschützten Header: Reject oder eng begrenzter, ausdrücklich unvertrauenswürdiger Hinweis. Sonst wird der Kompatibilitäts-Fallback zur verdeckten Sicherheitsrichtlinie.

Auch ein geschützter Claim belegt nur, dass bestimmte Bytes Teil einer erfolgreichen kryptografischen Operation mit einem Schlüssel waren. Er belegt nicht, dass der Schlüssel diesen Issuer für diese Objektklasse vertreten durfte, dass die Audience passt, dass der Claim frisch ist oder dass die Geschäftsaktion erlaubt ist.

Ebenso wichtig ist die Integrität der Interpretation. RFC 9597 empfiehlt typ aus RFC 9596, wenn der Anwendungskontext den Sinn nicht natürlich festlegt. Der Typ wählt den Validierungsvertrag; der Vertrag deutet die Claims. Ein geschützter Claim unter einem manipulierbaren Interpretationssignal ergibt keine geschützte Entscheidung.

Frühe Verarbeitung braucht eine harte Obergrenze

Issuer-basierte Schlüsselsuche ist das naheliegende Beispiel. Der Empfänger benötigt den Issuer, um den Schlüssel zu finden, mit dem er den Issuer validiert. Dieses Henne-Ei-Problem rechtfertigt eine Suche, aber kein Privileg.

Vor der Validierung darf ein Claim einen Suchraum, eine isolierte Queue oder ein kleines Ressourcenbudget wählen. Er darf nicht endgültig einen Tenant erzeugen, ein gemeinsames Cache befüllen, ein Abrechnungskonto setzen, unbegrenzt externe Dienste abfragen oder irreversible Zustände verändern.

Der vorläufige Beleg enthält empfangene Bytes, Position und Schutzklasse von Label 15, Claim-Wert, gewählten Zweig, Anfrage und Kandidaten. Der endgültige Beleg ergänzt kryptografisches Ergebnis, Interpretationsquelle, Profilversion, Payload-Vergleich, Audience, Zeitregeln, lokale Policy, Aktion und Wirkung.

RFC 9597 warnt vor der Nutzung von Claims, bevor ihre Integrität kryptografisch gesichert ist. Vorläufige Entscheidungen müssen nach Abschluss bestätigt werden. Deshalb müssen Tests einen erfolgreichen Lookup mit anschließend ungültiger Signatur, falschem Typ, falscher Audience und falschem detached content kombinieren. Rollback ist eine Produkteigenschaft, keine Anmerkung im Diagramm.

Heng Lus Running-Code Primacy liefert den Maßstab: Nicht die Zusage „wird später geprüft“, sondern der ausgeführte und beobachtete Rückbau beweist die Grenze.

Zwei Kopien verlangen eine eindeutige Vergleichsregel

RFC 7519 kennt eine ähnliche Replikation für JWT und JOSE. RFC 9597 verlangt normalerweise identische Werte, wenn ein CWT denselben Claim im Header und im Payload führt. Eine Anwendung darf nur mit spezifischen eigenen Regeln davon abweichen.

Damit kann ein Gateway nicht nach Issuer A routen, während die Anwendung Issuer B autorisiert, und beide Ergebnisse als einen Token behandeln. Eine Ausnahme muss festlegen, welche Komponente welche Kopie liest, welcher Schutz sie umfasst und warum die Abweichung sicher ist.

Gleichheit ist dennoch kein Wahrheitsbeweis. Zwei gleiche Werte können abgelaufen, für eine andere Audience oder von einem unzuständigen Schlüssel signiert sein. Die explizite Validierungsdisziplin aus RFC 8725 bleibt nach dem Vergleich erforderlich.

Sichtbarkeit durchbricht die Verschlüsselung bewusst

Ein vor der Entschlüsselung lesbarer Claim ist nicht verschlüsselt. Issuer kann eine Organisation, Subject ein Gerät oder eine Person, Audience einen Dienst und Token-ID eine korrelierbare Spur offenlegen. Wer alle Claims „für Observability“ kopiert, kann die Vertraulichkeit des Payloads ohne jeden Kryptografiebruch aushöhlen.

Das Profil sollte mit der minimalen Frage beginnen: Welcher eine Wert ist für die frühe Aufgabe nötig? Wer sieht ihn im Netz, Proxy, Queue, Log, Trace, Cache und Fehler? Wie lange bleibt er? Kann eine kurzlebige Routingklasse ein stabiles Subject ersetzen? Kryptografische Gültigkeit ist keine Veröffentlichungserlaubnis.

Die Minimum Initial Specification passt zu dieser Arbeitsteilung: gemeinsamer Container und Konsistenzregel; lokale Entscheidung über Offenlegung, Schlüsselkompetenz und Aktion.

Detached content verlängert den Beweisweg

COSE kann getrennt transportierten Inhalt schützen. RFC 9052 überträgt der Anwendung jedoch die Verantwortung, ihn unverändert zu transportieren. Ein korrekter Issuer belegt nicht, dass der Verifier die richtige Datei geladen hat.

Locator, Abrufkontext, exakte Bytes oder Hash und Bindungsergebnis müssen erhalten bleiben. Sonst kann ein legitimer früher Hinweis an den Payload einer anderen Transaktion geraten.

Der Schlussbeleg muss eng bleiben: Claim sichtbar; Wert und Interpretation durch dieses validierte Objekt geschützt; Payload-Kopie nach dieser Regel konsistent; lokale Policy erlaubt; Aktion versucht; Wirkung beobachtet. Die Reality Layers verhindern, dass ein früher Satz für alle späteren spricht.

Quellen