Zusammenfassung

  • kid ist in COSE ein unstrukturierter, nicht eindeutiger Suchhinweis für mögliche Schlüssel, keine kryptografische Fingerprint-, Geräte- oder Berechtigungsidentität.
  • Ein belastbarer Nachweis hält Suchraum, vollständige Kandidatenmenge, tatsächlich erfolgreichen Schlüsselfingerabdruck, geschützte Eingaben, Identitätsbindung, Autorisierungsregel und Wirkung auseinander.

Ein COSE_Sign1-Objekt erreicht einen Prüfdienst. Im ungeschützten Header steht kid = 0x19. Die lokale Ablage liefert zwei Treffer: einen alten Schlüssel aus einer noch offenen Rotationsphase und einen Schlüssel aus einem anderen Mandantenbereich. Der erste Versuch scheitert, der zweite bestätigt die Signatur.

Schreibt das System nun nur „0x19 gültig“, wird die Suche zur Identitätsbehauptung. Es fehlen die Ablageversion, der Namensraum, beide Kandidaten, der erfolgreiche Schlüssel und die Regel, die nach der kryptografischen Prüfung eine Handlung erlaubte. Das kurze Feld hat Aufgaben übernommen, die ihm nie zugewiesen wurden.

Das Beispiel behauptet keinen realen Vorfall. Es prüft, ob ein Betriebsmodell die ausdrücklich erlaubte Mehrdeutigkeit des Standards bewahren kann.

kid verkleinert die Suche

RFC 9052 ist die aktuelle Spezifikation für COSE-Strukturen und ihre Verarbeitung. In der Tabelle gemeinsamer Headerparameter erhält kid den Integer-Wert 4 und den Typ Bytefolge. Sein Wert kann mit dem gleichnamigen Feld eines COSE_Key oder einem äquivalenten Merkmal einer anderen Schlüsselverteilung verglichen werden.

Die Anwendung darf daraus keine Eindeutigkeit ableiten. Mehrere Schlüssel können denselben Wert tragen; unter Umständen müssen alle geprüft werden. Auch eine interne Struktur ist nicht definiert. Im COSE_Key kann die Kennung eine frei gewählte Bytefolge oder ein aus dem öffentlichen Schlüssel berechneter Wert sein und trotzdem bei verschiedenen Schlüsselobjekten wiederkehren.

Die fachlich richtige Ausgabe einer Abfrage ist deshalb eine Kandidatenmenge. Eingaben sind Anwendung, Aussteller oder Mandant, Version der Schlüsselablage, Zeitpunkt und empfangene Bytes. Erst eine erfolgreiche kryptografische Operation bestimmt, welcher vollständige Schlüssel für dieses Objekt funktioniert. Dessen Fingerabdruck ist ein eigener Befund, keine ausgeschriebene Form von kid.

Das IANA-COSE-Register hält die Drahtsemantik knapp fest: Label 4, bstr, Schlüsselkennung. Daneben gibt es den eigenständigen Parameter kid context. Nicht jedes Profil muss ihn verwenden; die getrennten Einträge zeigen jedoch, dass Wert und Geltungsraum nicht identisch sind.

Ungeschützt ist keine Vertrauensaussage

COSE-Sicherheitsobjekte enthalten geschützte und ungeschützte Headerparameter. Die geschützten Werte gehen in die authentisierte Konstruktion ein. Ungeschützte Werte werden mitgeführt, erhalten dadurch aber nicht dieselbe Integritätseigenschaft.

RFC 9052 nennt kid einen Hinweis zur Schlüsselauswahl und kein sicherheitskritisches Feld. Daher darf es im ungeschützten Bereich stehen. Diese Erlaubnis bedeutet nicht, dass eine Änderung betrieblich folgenlos wäre. Ein manipulierter Wert kann die Kandidatenzahl erhöhen, eine schlecht isolierte Ablage aufrufen, Rechenaufwand verursachen oder ein Protokoll irreführen. Er darf nur nicht selbst Grundlage des Sicherheitsurteils sein.

Die Änderung erzeugt keine gültige Signatur für einen fremden Schlüssel. Ein konkreter Kandidat muss weiterhin die Prüfung über den exakten Bytes bestehen. Begrenzte Suchen, Mandantentrennung und vollständige Versuchshistorien behandeln das Risiko, ohne dem Hinweis eine Authentizität anzudichten.

Die Signatur hat einen genauen Gegenstand

Für Signaturen baut RFC 9052 eine Sig_structure. Sie enthält den Signaturkontext, die geschützten Body-Parameter, gegebenenfalls geschützte Signer-Parameter, externe authentisierte Anwendungsdaten und die vollständige Nutzlast. Die Codierung ergibt ToBeSigned; geprüft wird mit diesem Bytewert, einem Algorithmus, dem tatsächlichen Schlüssel und der Signatur.

Ein Prüfbeleg sollte daher den Strukturtyp, die ursprünglichen geschützten Headerbytes, die Bildung von external_aad, den Hash der verarbeiteten Nutzlast und den Fingerabdruck jedes Kandidaten festhalten. Auch Ablehnungen wegen unbekannter kritischer Parameter oder fehlerhafter Maps gehören dazu, obwohl sie vor der eigentlichen Kryptografie eintreten.

Ein grünes Symbol darf nicht auf benachbarte Felder übergreifen. Kam kid aus dem ungeschützten Header, bleibt es auch dann ungeschützt, wenn die Oberfläche es unmittelbar neben „Signatur gültig“ zeigt.

Nach der Prüfung folgen Identität und Befugnis

RFC 9052 beendet das Verfahren nicht mit einem mathematischen Erfolg. Die Anwendung soll zusätzlich prüfen, ob der verwendete Schlüssel korrekt mit der Signer-Identität verbunden ist und ob diese Identität vor einer Handlung autorisiert ist.

Ein Zertifikat, eine Provisionierungsquittung, Attestierung oder ein lokal verwalteter Datensatz kann die erste Verbindung belegen. Rolle, Ressource, Zweck, Zeit und Policy-Version bestimmen die zweite. Eine historische Signatur kann weiterhin korrekt sein, obwohl der frühere Inhaber heute keine neue Anweisung erteilen darf. Zwei Rotationsschlüssel können dieselbe Kurzkennung tragen und dennoch andere Gültigkeitszeiten oder erlaubte Operationen haben.

Auch der Anwendungserfolg ist eine eigene Stufe. Eine Freigabe garantiert keinen Commit, und ein interner Commit beweist noch nicht die beobachtete Wirkung an einem entfernten System.

ACE belässt die Kennung beim Index

Abschnitt 10 von RFC 9052 überlässt dem jeweiligen Anwendungsprofil die Auswahl von Nachrichten, Diensten, Headern, Algorithmen und Aushandlung. COSE stellt gemeinsame Sicherheitsbausteine bereit; die konkrete Anwendung definiert ihre Zuständigkeit.

RFC 9200 macht die Grenze im ACE-OAuth-Rahmen greifbar. Bei einer Antwort des Authorization Server mit einem Proof-of-Possession-COSE_Key dient kid nur dazu, Indexierung und Abruf zu erleichtern. Eindeutigkeit darf weder im Bereich des Clients noch im Bereich des Resource Server vorausgesetzt werden.

Selbst in einem Autorisierungsprotokoll ist die Kennung also nicht die Berechtigung. Der Beleg braucht Profil und Version, Aussteller oder Authorization Server, Client, Audience, Resource Server, zulässige Schlüsselverwendung und Policy-Entscheidung.

Schaads Rolle bleibt dokumentierte Mitwirkung

Jim Schaad verfasste die ursprüngliche COSE-Spezifikation RFC 8152 von 2017. RFC 9052, ebenfalls mit J. Schaad im Autorenfeld, ersetzte später deren Strukturen und Prozesse; die Algorithmen wurden in RFC 9053 getrennt. Das IETF-Datatracker-Profil von Jim Schaad ordnet diese Dokumente in sein breiteres RFC-Werk ein.

Die RFCs sind IETF-Konsens und keine persönliche Verfügung. Autorschaft belegt weder eine konkrete Implementierung noch deren Sicherheit. Ein Nachruf der Oregon Wine Press enthält das öffentlich kreditierte Foto, das ausschließlich als Identitätsreferenz für das redaktionelle Porträt dient. Die dortige Weinkellerei ist keine COSE-Evidenz.

Auch erfolglose Kandidaten gehören zum Beleg

Der erste Datensatz beschreibt das empfangene Objekt: Hash, COSE-Struktur, geschützte und ungeschützte Header, externe Daten und Nutzlastreferenz. Die Abfrage wird separat mit Namensraum, Store-Version, Zeit, ursprünglichem kid und allen Treffern erfasst.

Jeder Kandidat behält Fingerabdruck, Herkunft, Gültigkeit, erlaubte Operationen und Ergebnis. Der erfolgreiche Schlüssel verweist auf den Hash von ToBeSigned. Danach werden Identitätsnachweis, Autorisierungsentscheidung und Anwendungsquittung angefügt.

Gescheiterte Kandidaten erklären Rotationsfenster, unterschiedliche Knotenantworten und geänderte Suchreihenfolgen. Werden sie gelöscht, wirkt die Kurzkennung im Rückblick immer eindeutig. Bleiben sie erhalten, lautet die Schlussfolgerung präzise: Dieser Schlüssel prüfte diese Bytes; dieser Nachweis verband ihn mit dieser Identität; diese Policy erlaubte oder verweigerte die Handlung; diese Wirkung wurde beobachtet.

Quellen