Zusammenfassung

  • Nennt die geschützte crit-Liste eine Erweiterung, die der Prüfer nicht versteht und unterstützt, ist die JWS trotz passender Signatur ungültig.
  • Die Regel verhindert, dass ältere Software eine zwingende Bedeutungsänderung überspringt und die Nachricht still nach früheren Regeln behandelt.
  • Kryptografisches Ergebnis, JOSE-Verarbeitung und fachliche Annahme brauchen getrennte Verantwortliche und Nachweise.

Wenn richtige Mathematik zur falschen Freigabe führt

Ein Dienst erhält eine JWS, findet den vorgesehenen Schlüssel, bildet den Signatureingang korrekt und bestätigt die Signatur. In vielen Systemen endet die Beobachtung an dieser Stelle mit einem grünen Status. Im geschützten Header steht jedoch eine Erweiterung, deren Name zusätzlich in crit auftaucht. Der Dienst hat sie nie implementiert.

RFC 7515 erlaubt ihm nicht, die Erweiterung zu übergehen. Für diesen Empfänger ist die JWS ungültig. Das mathematische Ergebnis wird dadurch nicht falsch; seine Aussage bleibt nur enger. Es belegt die Beziehung zwischen Bytes, Algorithmus und Schlüssel. Es belegt nicht, dass der Empfänger die durch diese Bytes verlangte neue Regel kennt.

crit ist ein Array von Headerparameternamen. Jeder Name muss eine tatsächlich im JOSE-Header vorhandene Erweiterung bezeichnen, die der Empfänger versteht und unterstützt. Die Liste darf nicht leer sein, keine Namen doppelt führen und keinen abwesenden Parameter nennen. Bereits durch JWS oder JWA definierte Standardparameter gehören ebenfalls nicht hinein.

Die Liste selbst darf ausschließlich im geschützten Header stehen. Wäre die Aussage darüber, was zwingend zu verstehen ist, ungeschützt, könnte ein Vermittler sie verändern, ohne die Signatur zu brechen. Unbekannte Parameter, die nicht als kritisch markiert sind, dürfen im Allgemeinen ignoriert werden. Diese Asymmetrie lässt optionale Ergänzungen zu und zwingt bei einer Bedeutungsänderung zum sicheren Abbruch.

Eine Fähigkeitsgrenze für langlebige Identitätssysteme

Nat Sakimura wird in RFC 7515 gemeinsam mit Michael B. Jones und John Bradley als Autor geführt. Seine langjährige Arbeit an Identitätsstandards und in der OpenID Foundation macht die institutionelle Aufgabe sichtbar, ohne ihm eine kollektive Spezifikation allein zuzuschreiben: Anbieter und Anwendungen aktualisieren sich nie gleichzeitig, während signierte Formate über Jahre weiterleben.

crit versucht nicht, künftige Erweiterungen vorwegzunehmen. Der Mechanismus verteilt vielmehr die Beweislast. Der Erzeuger erklärt geschützt, welche Erweiterungen für diese Nachricht unerlässlich sind. Der Empfänger darf erst weitergehen, wenn er jede davon nicht bloß erkennt, sondern nach ihrer Definition verarbeitet. Eine erfolgreiche Signaturprüfung hebt diese Pflicht nicht auf.

Das Wort „kritisch“ bezeichnet dabei keine allgemeine Gefahrenstufe. Entscheidend ist, ob Ignorieren die Konstruktion, Bedeutung oder Sicherheitseigenschaft der Nachricht verändert. Ein geschäftlich auffälliges Metadatum kann optional sein; ein unscheinbarer Kodierungsschalter kann den gesamten Signatureingang verändern. Erweiterungs- und Profilautoren müssen diese Grenze ausdrücklich festlegen.

Auch die Validierungsfolge in RFC 7515 trennt die Arbeiten: geschützten Header dekodieren und prüfen, verlangte Felder und Werte verstehen, Signatureingang erzeugen und kryptografische Operation ausführen. Eine Programmierschnittstelle mit nur einem valid-Boolean verwischt, welche dieser Bedingungen tatsächlich erfüllt wurde.

Warum b64:false nicht still übergangen werden darf

RFC 7797 liefert ein anschauliches Beispiel. Normalerweise verwendet JWS die base64url-kodierte Nutzlast im Signatureingang. Steht der geschützte Parameter b64 auf false, wird die nicht kodierte Nutzlast verwendet. Damit ändern sich genau die signierten Bytes und bestimmte Bedingungen der Serialisierung.

Eine solche JWS muss b64 zugleich in crit aufführen. Ein älterer Prüfer, der die Erweiterung nicht kennt, trifft auf einen unbekannten kritischen Namen und lehnt ab. Er kann die Nachricht nicht mit der gewohnten Kodierungsregel behandeln und ein beliebiges erfolgreiches Rechenergebnis anschließend als gemeinsame Interpretation ausgeben.

Selbst technische Unterstützung bedeutet noch keine Zulassung. Anwendungsprofile sollen die Einstellung konsistent einsetzen, und bei der kompakten Serialisierung sind nicht alle Nutzlastzeichen unproblematisch. JWT darf b64:false ausdrücklich nicht verwenden. Eine generische JWS-Bibliothek kann die Erweiterung fehlerfrei prüfen, während die JWT-Anwendung dieselbe Kombination ablehnen muss.

Drei Fragen bleiben daher getrennt: Passt die Signatur zum gebildeten Eingang? Wurden alle kritischen Erweiterungen verstanden und korrekt angewendet? Erlaubt das konkrete Nachrichtenprofil diese Verwendung? Das erste Ja hat keine Entscheidungsgewalt über die beiden folgenden.

Ausführbar ist nicht automatisch zulässig

RFC 7518 definiert Algorithmen und Bezeichner für JOSE. Dass eine Implementierung einen Algorithmus kennt und ausführen kann, macht ihn nicht in jeder Umgebung akzeptabel. RFC 7515 überlässt der Anwendung die Auswahl zulässiger Algorithmen. Eine rechnerisch richtige Signatur kann daher an Algorithmus-, Schlüssel- oder Parameterpolitik scheitern.

RFC 8725 konkretisiert diese Trennung für JWT. Systeme sollen Algorithmen ausdrücklich beschränken und das Prüfverfahren nicht allein aus vom Absender kontrollierten Angaben wählen. Aussteller, Subjekt, Zielgruppe und profilspezifische Regeln müssen validiert werden. Verschiedene JWT-Typen können voneinander ausgeschlossene Prüfregeln benötigen, damit ein Token nicht in den falschen Zweck wechselt.

crit ersetzt keine dieser Entscheidungen. Der Parameter bestätigt weder einen vertrauenswürdigen Aussteller noch die richtige Zielgruppe und genehmigt keine Geschäftshandlung. Auch eine beidseitig bekannte Erweiterung ist nicht automatisch sicher oder in jedem Profil erlaubt. Verständnis ist eine Voraussetzung für Bewertung, nicht deren Ergebnis.

Mehrere Signaturen brauchen eine benannte Schwelle

Die JSON-Serialisierung von JWS kann mehrere Signaturen enthalten. In der allgemeinen Beschreibung von RFC 7515 muss mindestens eine gültig sein; eine Anwendung darf strengere Bedingungen setzen. Jede Signatur besitzt einen eigenen geschützten Header und kann daher andere kritische Erweiterungen mitbringen.

Bei einer Migration kann eine neue Signatur einen neuen Algorithmus oder eine neue Semantik einführen, während eine alte den Übergang absichert. Bleibt die Regel „irgendeine genügt“ ohne Ablaufdatum bestehen, wird der alte Weg zur dauerhaften Herabstufung. Verlangt man sofort alle, fallen legitime Empfänger aus, die die Erweiterung noch nicht verstehen.

Der Betreiber muss deshalb bestimmen, welche Signaturen zählen, welche Schlüssel und Erweiterungen zulässig sind, für welche Zielgruppen der Übergang gilt und wann der alte Pfad endet. Die Protokollierung muss zeigen, welche Signatur die Schwelle erfüllte. Ein aggregiertes Erfolgssignal kann nicht sagen, ob die Umstellung vorankommt oder der gesamte Verkehr weiter auf der Ausnahme beruht.

Ein Nachweis mit drei klaren Urteilen

Der kryptografische Datensatz enthält Algorithmus, Schlüsselreferenz, Konstruktion des Signatureingangs und Ergebnis. Der JOSE-Datensatz enthält den geschützten Header, angetroffene kritische Namen, den zuständigen Erweiterungsprozessor und Ablehnungen wegen fehlenden Verständnisses. Der Anwendungsdatensatz verbindet Profil, Aussteller, Zielgruppe, Claim-Regeln, Autorisierungsentscheidung und beabsichtigte Wirkung.

Weder geheime Schlüssel noch vollständige Token müssen dafür protokolliert werden. Stabile Korrelationsmerkmale und präzise Gründe reichen. „Ungültige Signatur“ ist irreführend, wenn die Signatur stimmte, aber eine Erweiterung unbekannt war. „Gültiges Token“ ist gefährlich unvollständig, wenn die JOSE-Verarbeitung gelang, die Anwendung aber die Zielgruppe ablehnte.

Die tiefere Funktion von crit ist eine Pflicht zur semantischen Redlichkeit. Ein Empfänger darf nicht behaupten, eine Nachricht verstanden zu haben, nur weil er ihren Umschlag authentifiziert hat. Sakimura und seine Mitautoren machten das Eingeständnis fehlender Fähigkeit zu einem korrekten und sicheren Protokollergebnis.

Quellen