Zusammenfassung

  • CBOR-Tag 601 bezeichnet einen CWT Claims Set ohne eigene Signatur, MAC oder Verschlüsselung.
  • Im RATS-Einsatz stammen Authentizität und Integrität aus einem passend aufgebauten Kanal; Endpunktrollen, Offenlegungsbefugnis und Replay-Schutz bleiben nachzuweisen.
  • Nach der Extraktion schützt der alte Kanal das Objekt nicht mehr. Bei einer Weiterleitung wird der Empfänger zur operativen Quelle.

Der Cache erbte keine Sitzung

Ein Attester sendet Claims an ein Gateway. Das Gateway authentifiziert den Peer, prüft die Integrität, liest die CBOR-Map und legt sie in einem Cache ab. Ein späterer Dienst findet Tag 601, einen passenden Hash und plausible Claims. Trotzdem hat er den authentifizierten Austausch nie gesehen.

UCCS erlaubt eine sinnvolle Ressourceneinsparung. Ein gewöhnlicher CWT trägt eine COSE-Hülle, die Herkunft und Integrität des Objekts absichern kann. Wenn genau die beteiligten Rollen bereits eine geeignete Sicherheitsbeziehung besitzen, kann doppelte Kryptografie unnötig sein. RFC 9781 lässt dann den Claims Set ohne COSE-Hülle übertragen und kennzeichnet ihn mit #6.601.

Der Tag ist ein Typ, kein Vertrauensurteil. Er enthält keinen Schlüssel, keinen Absender, keine Sitzung und keinen Nonce. Die IANA-Zuweisung verhindert Bedeutungsüberschneidungen; sie beweist keine Implementierung.

Für RATS muss der Empfänger den Absender beim Kanalaufbau authentifizieren, und der Kanal muss die Integrität der Kommunikation schützen. Ist Vertraulichkeit erforderlich, muss auch der Empfänger authentifiziert sein. Ein belastbarer Beleg nennt daher Protokoll, Version, kryptografische Parameter, Authentifizierungsrichtung, Zertifikat oder anderes Credential, Vertrauensanker, Rollen, Sitzungszeit und gebundene Bytes.

Replay-Schutz ist ein eigener Befund. RFC 9781 nennt einen Nonce-Claim als Möglichkeit. TLS 1.3 unterscheidet zudem reguläre 1-RTT-Daten von 0-RTT. Eine bestätigte Identität beweist nicht, dass ein Claim neu ist.

Die Claims dürfen auch nicht das Credential beglaubigen, das denselben Kanal aufgebaut hat. Diese Begründung wäre zirkulär. Ebenso beweist ein authentifizierter Endpunkt noch keine vertrauenswürdige Attesting Environment: Ein Kanal kann falsche Messwerte unverändert liefern.

Am Ausgang wechselt die Quelle

Abschnitt 4 sagt klar, dass ein UCCS nach dem Eintritt in die Empfängerumgebung nicht mehr durch die Eigenschaften des Kanals geschützt ist. Leitet der Empfänger es weiter, wird es so behandelt, als stamme es aus dem Empfänger.

Damit wird das Gateway zum verantwortlichen Akteur. Es wählt Parser, Normalisierung, Speicherort, Aufbewahrung, Empfänger und nächste Schutzform. Der Folgedienst erhält nicht den alten Kanal, sondern eine Aussage des Gateways über früher empfangene Bytes.

Der Extraktionsbeleg verbindet den Rohdaten-Hash mit Sitzung, Peer-Identität, Prozess, Parser-Version und Zeitpunkt. Bei einer Umkodierung hält er Hashes vor und nach der Transformation fest. Der Verwahrungsbeleg nennt Schreiber, Objekt-ID, Zugriffspolitik, Ruhendverschlüsselung, Frist und Löschung. Der Weiterleitungsbeleg nennt Eingabe-Hash, neue Quelle, Transformation, neuen Kanal oder neue Signatur, Zielgruppe und Bestätigung.

Ein Hash beweist Gleichheit, aber nicht die Verbindung zur Sitzung. Verschlüsselung im Speicher schützt das Repository, signiert jedoch nicht rückwirkend den Absender. Eine neue TLS-Verbindung authentifiziert das Gateway gegenüber dem nächsten Dienst, nicht den ursprünglichen Attester.

Delegierte Attestation zeigt einen sauberen Übergang. Ein Sub-Attester ohne Signaturschlüssel sendet UCCS über einen lokalen sicheren Kanal an einen Lead Attester. Dieser bildet den Hash und schützt ihn mit seinem Evidence-Schlüssel, etwa in einer abgetrennten EAT-Struktur. Der Lead Attester übernimmt sichtbar die Verantwortung für die neue Aussage.

Ein vollständig geformter CWT bleibt davon verschieden. Seine COSE-Hülle trägt eine eigene Herkunfts- und Integritätskette. Der Transportkanal authentifiziert seinen Peer, nicht automatisch den inneren Signierer.

Von der Map zur Entscheidung

Neun Belege dürfen nicht zusammenfallen: Format und Bytes, Kanalaufbau, Endpunktidentität, Frische, Extraktion, Verwahrung, Weiterleitung, Verifier-Bewertung und Relying-Party-Aktion. RFC 9334 weist die Bewertung und die anwendungsspezifische Entscheidung unterschiedlichen Rollen zu.

Wenn ein Empfänger zur Quelle wird, muss die Bewertung benennen, ob sie die ursprüngliche Umgebung, die neu geschützte Empfängeraussage oder eine nachvollziehbare Verbindung beider prüft. Sonst ersetzt ein Transporthelfer unbemerkt die Autorität.

RFC 9781 beschränkt die gemeinsame Ebene auf das Nötige: Datenform, Kanaleigenschaften und Ende der Vererbung. Die Veröffentlichung des Standards ist symbolische Realität. Erst laufende Authentifizierung, Nonce-Prüfung, Verwahrung und Entscheidungsprotokolle machen die Zusicherung ausführbar.

Quellen