Zusammenfassung

  • RFC 9782 registriert sechs Medientypen für CWT, JWT, abgesetzte Bundles und ungeschützte Claim-Sets sowie +cwt und sechs CoAP-Nummern.
  • Der optionale Parameter eat_profile ermöglicht frühes Routing, beweist aber weder Übereinstimmung mit dem internen Claim noch vollständige Profilkonformität.
  • Format, kryptografischer Schutz oder Kanal, Frische, Verifier-Bewertung und Entscheidung der Relying Party brauchen jeweils einen eigenen Beleg.

Sechs Formen, ein begrenztes Versprechen

In RATS fließen Evidence und Attestation Results zwischen Attester, Verifier und Relying Party. RFC 9782 definiert nicht neu, was diese Rollen glauben sollen. Es gibt ihren HTTP- und CoAP-Schnittstellen vielmehr eindeutige Bezeichnungen für das, was transportiert wird.

application/eat+cwt und application/eat+jwt stehen für EAT in den beiden Tokenfamilien. Zwei weitere Typen kennzeichnen abgesetzte EAT-Bundles in CBOR und JSON; die letzten beiden UCCS und UJCS, also Claim-Sets ohne eigenen kryptografischen Umschlag. CoAP verwendet für dieselben Formen die Content-Formats 263 bis 268. Der strukturierte Suffix +cwt erlaubt generische CWT-Verarbeitung.

Damit kann ein Gateway eine nicht unterstützte Form früh ablehnen, über Accept eine Antwort aushandeln und einen spezialisierten Parser wählen. Der Suffix nennt jedoch keinen Aussteller, keinen erlaubten Algorithmus, keine Schlüsselquelle, keine Pflicht-Claims und keine Frischemethode. Auch beweist ein Bundle-Typ nicht, dass abgesetzte Daten zu den geschützten Digests passen.

Bei UCCS und UJCS wird diese Grenze praktisch. RFC 9781 verlangt in RATS einen sicheren Kanal, der den Sender authentifiziert und Integrität schützt; für Vertraulichkeit muss auch der Empfänger authentifiziert sein. Verlässt das Claim-Set den Kanal, endet dessen Schutz. Speicherung und Weitergabe sind neue Übergaben. Ein vollständiger CWT im selben Kanal wird dagegen nicht durch den Kanal verbürgt, sondern durch seinen eigenen COSE-Prüfpfad.

Ein sichtbares Profil ist zunächst eine Behauptung

EAT-Profile schränken offene Wahlmöglichkeiten ein: JSON oder CBOR, Verschachtelung, COSE/JOSE-Strukturen und Algorithmen, Schlüsselidentifikation, Bundles, Claims und Frische. Im Token identifiziert eat_profile das Profil. RFC 9782 erlaubt denselben Wert als Parameter des Medientyps, damit ein Router schon vor dem Lesen des Bodys den Profilprozessor bestimmen kann.

Das ist ein sinnvoller Kontrollpunkt. Unbekannte Profile werden am Rand sichtbar; ein Universalparser muss weniger raten. Trotzdem stammt der externe Parameter vom Absender. Nach sicherer Dekodierung muss der Empfänger Abwesenheit, Gleichheit und Widerspruch zum internen Claim unterscheiden. Ein Widerspruch kann Fehlkonfiguration, veraltete Vermittlung oder Substitution anzeigen und darf nicht stillschweigend bereinigt werden.

Auch Gleichheit ist noch keine Konformität. RFC 9711 verbietet, mit eat_profile ein Teilprofil zu benennen. Ein vollständiges Profil muss so bestimmt sein, dass ein konformer Empfänger jedes EAT eines konformen Senders dekodieren, verifizieren und auf Frische prüfen kann. Eine richtige URI kann neben einem verbotenen Algorithmus oder fehlenden Pflicht-Claim stehen. Der Name lädt die Prüfliste; laufender Code muss sie erfüllen.

Die Bytes haben Vorrang vor dem Etikett

RFC 9782 nennt Medientypen ausdrücklich nur Hinweise für die verarbeitende Anwendung. Diese muss unabhängig vom beworbenen Typ prüfen, ob die Daten dem erwarteten Format entsprechen, und bei einem Fehler stoppen. Sonst drohen Protokollverwechslung und Rechteausweitung. RFC 9110 warnt entsprechend vor falschem Content Sniffing; RFC 8725 verlangt für unterschiedliche JWT-Arten explizite Typisierung und gegenseitig ausschließende Validierungsregeln.

Ein belastbarer Ablauf speichert daher den rohen Header und den Hash der Bytes, dann Route, Handler und Parser. Danach folgt ein Schutzbeleg mit Umschlag, Algorithmus, Schlüssel, Trust Anchor und Ergebnis – oder bei ungeschützten Sets die Identität und zeitliche Reichweite des Kanals. Abgesetzte Bundles benötigen für jedes externe Claim-Set einen Digest-Vergleich.

Erst anschließend werden Claims interpretiert. RFC 9711 legt ihre Bedeutung fest, nicht das Sicherheitsniveau der Messquelle. Eine gültige Signatur ordnet Bytes einem Schlüsselmodell zu; sie beweist keine zuverlässige Messung. Der Verifier benötigt Wissen über Implementierung, Endorsements, Referenzwerte und Appraisal Policy.

Frische bleibt separat. Jede EAT-Nutzung muss Replay verhindern; das Profil bestimmt Nonce, Zeit oder ein anderes Verfahren. Ein authentisches Token kann veraltet sein. Signatur und Frische dürfen deshalb nicht in einem pauschalen „gültig“ verschwinden.

Schließlich erzeugt der Verifier Attestation Results, während die Relying Party mit eigener Policy eine anwendungsbezogene Handlung auswählt. Sie kann trotz günstigem Ergebnis verweigern, weil Ressource, Zeitfenster oder Risiko abweichen. RFC 9782 bringt die Nachricht zum richtigen Entscheider, ersetzt ihn aber nicht.

Die Beweiskette lautet: äußerer Typ und Profil → Bytes → Handler → Schutz → internes Profil und Claims → Konformität und Frische → Appraisal → Handlung. IANA-Registrierung schafft symbolische Wirklichkeit. Nach Heng Lus Running-Code-Prinzip entsteht operative Wirklichkeit erst durch Implementierungen, negative Tests und beobachtete Übergänge.

Quellen