Zusammenfassung

  • RFC 9596 registriert den geschützten COSE-Parameter typ mit Label 16 für den Typ des gesamten Objekts; der content type aus RFC 9052 bezeichnet dagegen Payload oder Ciphertext.
  • Die COSE-Bibliothek reicht typ an die Anwendung weiter, ohne ihn zu deuten. Sicherheit entsteht erst durch anwendungsspezifische Erwartungs-, Ablehnungs-, Schlüssel- und Autorisierungsregeln.

Die Signatur eines COSE-Objekts ist gültig. Im geschützten Header steht genau der Typ, den der Endpunkt erwartet. Damit ist eine Verzweigung möglich, aber noch keine Handlung gerechtfertigt.

RFC 9596 schließt eine Funktionslücke zwischen COSE und JOSE: Anwendungen können den Typ der vollständigen Struktur erklären und dadurch Objektklassen auseinanderhalten. Die Spezifikation gibt einer allgemeinen Kryptobibliothek jedoch nicht die Deutungshoheit über das Geschäftsprotokoll. Die Bibliothek liefert den Wert, die Anwendung bestimmt seine Wirkung.

Das ist eine bewusst enge Zuständigkeit. Ein Name kann einen Prüfpfad auswählen. Er kann nicht das Ergebnis aller Prüfungen vorwegnehmen.

Objekttyp und Payload-Typ sind zwei Achsen

RFC 9052 definiert content type für die Daten im Payload- oder Ciphertext-Feld. RFC 9596 definiert typ für das gesamte COSE-Objekt. Beide verwenden dieselbe Syntaxfamilie, beantworten aber verschiedene Fragen.

Ein signierter Beleg, ein Attestation Result und ein Statusereignis können alle CBOR tragen. Der innere Parser sieht dieselbe Kodierungsfamilie. Die äußere Anwendung braucht trotzdem andere Pflichtfelder, Schlüsselzwecke, Audiences und erlaubte Folgen.

Der Wert von typ ist entweder eine vorzeichenlose Zahl aus den CoAP Content-Formats oder ein textueller Medientyp mit möglichen Parametern. Ein Empfänger sollte die empfangene Form bewahren. Eine Zahl und ein Textalias können in einer Policy als gleich gelten und dennoch unterschiedliche Implementierungspfade auslösen.

Wer nur einen normalisierten „Typ“ protokolliert, verliert die Schicht, die Darstellung und die konkrete Vergleichsgrundlage. Später lässt sich dann nicht mehr sagen, ob die Hülle, der Inhalt oder beides geprüft wurde.

Kryptografischer Schutz macht eine Aussage nicht richtig

RFC 9596 verbietet typ im ungeschützten Header. Bei einer COSE-Struktur, die geschützte Header authentisiert, kann ein Mittler den Typ nicht ändern, ohne die Prüfung zu zerstören. Die Deklaration bleibt am signierten Objekt befestigt.

Der Signierer selbst kann sich trotzdem irren oder täuschen. Er kann einen veralteten Alias, einen Typ für einen anderen Endpunkt, unzulässige Parameter oder den richtigen Typ um den falschen Payload signieren. Integrität bewahrt die falsche Aussage genauso zuverlässig wie die richtige.

Darum ignoriert eine COSE-Implementierung den Parameter inhaltlich und reicht ihn nur weiter. Die Anwendung sollte einen unerwarteten Typ zurückweisen. Erwartet ihr Profil explizite Typisierung, sollte auch das Fehlen zum Abbruch führen.

Die Ablehnung ist der eigentliche Kontrollpunkt. Ein Decoder, der typ anzeigt, aber bei Fehlern auf einen generischen Handler zurückfällt, hat keinen isolierten Typraum geschaffen.

Getrennte Namen brauchen getrennte Validatoren

RFC 9596 verweist auf RFC 8725. Dort schützt explizite JWT-Typisierung vor Verwechslung verschiedener Tokenarten. Die anschließende Forderung ist ebenso wichtig: Die Validierungsregeln dieser Arten müssen sich gegenseitig ausschließen.

Wenn zwei COSE-Typen dieselben Schlüssel ohne Zweckbindung, dieselben Standard-Audiences und einen großzügigen Claims-Parser verwenden, können unterschiedliche Labels auf dieselbe Akzeptanzfläche führen. Ein alter Pfad, der typ ignoriert, genügt für die Substitution.

Der Typ muss einen vollständigen Vertrag auswählen: erlaubte COSE-Struktur, erforderliche geschützte Parameter, Payload-Typ, Pflicht-Claims, Issuer, Audience, Schlüsselzweck, Gültigkeit, Replay-Regel, Endpunkt und Operation. Der falsche Typ muss scheitern, bevor gemeinsame Geschäftslogik die Unterschiede verwischt.

RFC 8725 warnt, dass ältere Anwendungen typ häufig nicht berücksichtigen. Deshalb beweist die Quote markierter Sender keine abgeschlossene Migration. Entscheidend sind Empfängerregel, Version und beobachtete Negativtests.

Die Registry koordiniert Bezeichner, nicht Vertrauen

IANA führt typ als COSE-Headerparameter 16. Die Werte verweisen auf Media Types oder CoAP Content-Formats. So können unabhängige Implementierungen kollisionsfrei über eine gemeinsame Bedeutung sprechen.

Die Registry weiß nicht, ob ein Endpunkt den Typ freigegeben hat, ob der Schlüssel ihn signieren durfte, ob Parameter erlaubt sind oder ob der Payload dem Profil entspricht. Registrierung ist ein Namespace-Beleg, keine Berechtigung.

Drei Ebenen sollten sichtbar bleiben: die öffentliche Benennung, die versionierte lokale Akzeptanzpolitik und der konkrete Entscheidungsbeleg. Eine globale Liste „bekannter Typen“ darf nicht unbemerkt zur Liste „vertrauenswürdiger Typen“ werden.

Das entspricht der Minimum Initial Specification: Der Standard setzt den kleinsten gemeinsamen Rahmen. Spätere Entscheidungen bleiben lokal. Freiwillige Übernahme wird durch implementierte Prüfungen, Ablehnungen und Interoperabilität sichtbar, nicht durch eine Zeile in einem zentralen Katalog.

Die Beweiskette endet erst nach der Wirkung

Ein belastbarer Empfangsbeleg enthält Hash der Originalbytes, COSE-Struktur, geschützte Headerbytes, exakten typ-Wert und Darstellung, Payload-content-type, Endpunkt, Operation, erwartete Typen, Regelversion, Kryptografieergebnis, Schlüssel und Zweck, Parsing, Pflicht-Claims, Issuer, Audience, Frische, Replay-Prüfung, Autorisierungsentscheidung, Handler und beobachtete Wirkung.

Eine gültige Signatur belegt die Beziehung von Schlüssel und Bytes. Der passende Typ belegt die erwartete Deklaration. Parsing belegt Form. Das Profil belegt begrenzte Semantik. Schlüsselpolitik belegt Zuständigkeit. Lokale Autorisierung entscheidet die Operation. Erst das Ergebnis belegt die Wirkung.

Kein Baustein sollte für eine spätere Schicht sprechen. Die Kryptobibliothek kennt die Geschäftsentscheidung nicht. Die Media-Type-Registry kennt den Schlüssel nicht. Der Geschäftsservice darf eine abgelehnte Handlung nicht als ungültige Signatur zurückschreiben.

Die Reality Layers aus docs/heng-lu-note.md schützen gerade vor dieser Aufwertung eines Symbols. RFC 9596 liefert einen präzisen, geschützten Hinweis. Running Code muss zeigen, dass der richtige Prüfpfad tatsächlich durchgesetzt wurde.

Quellen