Zusammenfassung

  • Revision 06 soll JWS none und JWE RSA1_5 als Deprecated, nicht als Prohibited kennzeichnen: Anwendungen müssen beide standardmäßig abschalten, dürfen sie aber für genau bestimmte Objekte oder Vorgänge ausnahmsweise aktivieren.
  • Das aktive IANA-Register hatte die vorgeschlagene Änderung am 29. September 2026 noch nicht übernommen; selbst ein künftiger Statuswechsel belegt weder den Ausbau einer Bibliotheksfähigkeit noch die Ablehnung eines konkreten Aufrufs.
  • Ein belastbarer Stilllegungsnachweis verbindet Objekt und Vorgang mit alg und enc, der aufgelösten Positivliste, der kompilierten Fähigkeit, Eigentümer und Ablauf der Ausnahme, dem Ergebnis sowie der dadurch gewährten Autorität.

Eine Organisation kann zwei widerspruchsfreie Wahrheiten besitzen: „Der Algorithmus ist veraltet“ und „dieser Kunde darf ihn weiterhin verwenden“. Das Problem entsteht, wenn die erste Aussage im Risikobericht steht und die zweite nur in einer kaum bekannten Konfigurationsdatei. Dann wird eine Empfehlung mit einer durchgesetzten Grenze verwechselt.

Die Revision 06 von „JOSE: Deprecate 'none' and 'RSA1_5'“ erschien am 25. September 2026. Laut Datatracker-Eintrag befindet sich das Internet-Draft bis zum 9. Oktober im IETF Last Call; eine IANA-Prüfung ist noch erforderlich. Die Dokumenthistorie belegt den normativen Prozess, nicht die Umstellung einer produktiven Anwendung.

Die beiden Kennungen betreffen verschiedene Mechanismen. JWS none steht für ein Unsecured JWS ohne Signatur und ohne MAC. RFC 7515 definiert JWS, während RFC 7518 schon bisher verlangte, ungeschützte JWS nicht standardmäßig anzunehmen. Darf der eingehende alg-Wert selbst den Prüfpfad auswählen, kann eine nicht vertrauenswürdige Eingabe die Authentizitätsprüfung abschalten.

JWE RSA1_5 bezeichnet dagegen RSAES-PKCS1-v1_5 als Schlüsselmanagementverfahren im Verschlüsselungsmodell von RFC 7516. Es ist nicht mit RS256, RS384 oder RS512 gleichzusetzen. Diese sind JWS-Signaturverfahren; RSA1_5 ist eine Kennung für die Schlüsselverschlüsselung. Eine pauschale Sperre aller Namen mit „RSA“ kann legitime Signaturen brechen und dennoch den anfälligen Pfad verfehlen. RFC 8017 beschreibt die zugrunde liegenden RSA-Verfahren. Die aktuelle CFRG-RSA-Empfehlung macht deutlich, dass einheitliche Fehlerbehandlung und Orakelresistenz von der Implementierung abhängen.

Der Entwurf verteilt vier Pflichten. Bibliotheksentwickler sollten die Unterstützung als veraltet kennzeichnen. Anwendungsentwickler müssen beide Optionen standardmäßig deaktivieren. Besteht ein konkreter Bedarf, darf eine Option ausschließlich für die betreffenden Objekte oder Vorgänge freigeschaltet werden, niemals global. Neue JOSE-Spezifikationen dürfen keine der beiden Optionen erlauben.

Das ist eine kontrollierte Übergangsregel, keine Behauptung, die Funktion sei verschwunden. Beantragt wird bei IANA der Status Deprecated, nicht Prohibited. Bestehende Spezifikationen und Anwendungen behalten damit einen Migrationspfad. Zum Recherchezeitpunkt führte das IANA-JOSE-Register none noch als Optional und RSA1_5 als Recommended-. Eine spätere Registeränderung schreibt weder Mandantenkonfigurationen noch Gateways, SDKs, Hardwaremodule oder Ausnahmeverzeichnisse automatisch um.

Der Nachweis muss deshalb am Entscheidungspunkt ansetzen. Zu erfassen sind die JOSE-Objektklasse und der Geschäftsvorgang; der geschützte alg-Wert und bei JWE enc; Aussteller, Zielgruppe, Mandant und Route; die nach diesen Selektoren tatsächlich geltende Positivliste; Bibliotheksversion und einkompilierte Fähigkeiten; Herkunft, Genehmiger, Umfang und Ablaufdatum jeder Ausnahme; Schlüsseltyp; Annahme oder Ablehnung; sowie die Identität oder Handlung, die das Ergebnis autorisierte.

Bei JWE gehört auch die Fehlergestalt in den Datensatz. Unterschiede bei Meldung, Länge oder Laufzeit können einen Entschlüsselungsdienst zum Orakel machen, obwohl das Dashboard RSA1_5 als Sonderfall bezeichnet. NIST SP 800-131A Revision 2 liefert einen Rahmen für Übergänge, aber keinen Beweis für gleichförmige Fehlerpfade in einem lokalen Dienst.

RFC 8725 fordert bei JWT die Prüfung des Algorithmus und warnt vor Angreifer-kontrollierten Auswahlentscheidungen. Der Header beschreibt damit eine gewünschte Verarbeitung; er erteilt nicht die Befugnis, den Prüfer auszuwählen. Diese Befugnis liegt in der wirksamen Anwendungsrichtlinie.

Für künftige Registereinträge nennt der Entwurf weitere Maßstäbe: JWS-Signatur- und MAC-Verfahren sollten EUF-CMA erfüllen, der gesamte JWE-Verschlüsselungsprozess IND-CCA2, und die Inhaltsverschlüsselung sollte AEAD gemäß RFC 5116 bieten. Diese Kriterien unterstützen die Entwurfsprüfung. Sie sind weder Messergebnisse für ein konkretes Build noch ein Ersatz für korrekte Schlüssel-, Parser- und Richtlinienkomposition.

Heng Lus Vorrang des laufenden Codes stellt das tatsächliche Annahmeereignis über die Inventarbezeichnung. Die Realitätsebenen trennen die symbolische Veraltung von der operativen Tatsache, dass eine Nachricht Autorität erhalten hat. Die minimale Ausgangsspezifikation erklärt, warum die gemeinsame Regel einen sicheren Standard setzen kann, während das lokale System für enge Ausnahmen verantwortlich bleibt.

Die Stilllegung ist erst abgeschlossen, wenn alle relevanten Laufzeitpfade standardmäßig ablehnen und jedes verbleibende Ja präzise begrenzt, zugeordnet, messbar und befristet ist. Bis dahin ist Deprecated ein Warnschild am Eingang, kein Beleg vom Entscheidungspunkt.

Quellen