Zusammenfassung

  • Am 6. September übergab die JOSE-Arbeitsgruppe die Revision 05 zur Veröffentlichung an das IESG. „Publication Requested“ ist weder IESG-Genehmigung noch RFC oder bereits ausgeführte Änderung des IANA-Registers.
  • Der Entwurf verlangt eine Deaktivierung von none und RSA1_5 als Voreinstellung und sperrt sie für neue JOSE-Spezifikationen. Bestehende Anwendungen dürfen sie für bestimmte Objekte oder Vorgänge aktivieren. Solche Ausnahmen brauchen eine lokale Frist.

Ein Prozessschritt mit vier verschiedenen Pflichten

Der Datatracker verzeichnet für den 6. September 2026 den Wechsel zu „Submitted to IESG for Publication“ und „Publication Requested“. Deb Cooley wurde als zuständige Area Director eingetragen, zugleich erschien der Shepherd-Bericht.

Die Revision 05 vom 23. Juni bleibt dennoch ein Internet-Draft. Das IESG hat sie nicht verabschiedet, und IANA hat die vorgeschlagenen Änderungen nicht umgesetzt. Zum Prüfzeitpunkt stand none im JOSE-Register weiterhin auf Optional und RSA1_5 auf Recommended-. Das ist ein unfertiger Verfahrensstand, kein Beleg für Widerstand.

Der Entwurf würde RFC 7518 aktualisieren. Entwickler von JOSE-Bibliotheken SOLLTEN die Unterstützung abwerten. Anwendungsentwickler MÜSSEN sie standardmäßig deaktivieren. Eine Anwendung mit besonderem Bedarf DARF einen Algorithmus nur für die betroffenen Objekte oder Vorgänge aktivieren, nicht global. Neue JOSE-Spezifikationen DÜRFEN beide nicht mehr zulassen.

„Deprecated“ bedeutet bewusst nicht „Prohibited“. Vorhandene Spezifikationen und Anwendungen können die Verfahren weiter nutzen, sollen aber bei künftigen Änderungen auf Alternativen wechseln. Die RSA-Signaturen RS256, RS384 und RS512 bleiben unberührt. RSA1_5 bezeichnet hier das JWE-Schlüsselmanagement RSAES-PKCS1-v1_5.

Deshalb sind Registerstatus, Bibliotheksfunktion, Anwendungskonfiguration und beobachtete Transaktion getrennte Tatsachen. Wer sie zu einem Ja-Nein-Siegel verdichtet, verliert die Grenze der Ausnahme.

Weshalb es eine Ausnahme gibt

none erzeugt ein ungesichertes JWS ohne Signatur oder MAC. RFC 7518 untersagte schon die Annahme als Voreinstellung, doch der neue Text führt zahlreiche Schwachstellen an, bei denen Implementierungen den Wert versehentlich akzeptierten. RSA1_5 nutzt RSA-Verschlüsselung mit PKCS-#1-v1.5-Padding, dessen Probleme seit Bleichenbachers Angriff von 1998 bekannt sind. Der Entwurf nennt OAEP und elliptische Kurven als Alternativen und verweist auf die Übergangsrichtlinie des NIST für US-Bundesstellen.

Gleichzeitig existieren historische Abhängigkeiten. OpenID Connect Core beschreibt unverschlüsselte ID Tokens, deren Übertragung durch TLS geschützt wird, sowie unsignierte Request Objects. Der Shepherd-Bericht erklärt, dass die Debatte nach IETF 124 in einen zweiwöchigen Konsensaufruf im Februar 2026 mündete. Der Kompromiss erkennt diese Fälle an, hält aber an der Abwertung fest.

Im verlängerten Working Group Last Call gab es laut Bericht Unterstützung und keinen Widerspruch. Eine Umfrage bei IETF 126 ergab 27 Stimmen für die Veröffentlichung, null dagegen und acht ohne Meinung. Das trägt die Weitergabe an das IESG. Es ist keine Zählung von Installationen oder Abhängigkeiten.

IANA soll nicht zum Konfigurationsregister werden

IANA kann Bedeutung, Referenz, Change Controller und Empfehlungsgrad eines Algorithmus veröffentlichen. Der Entwurf würde zudem die Prüfung künftiger Einträge schärfen: EUF-CMA für JWS-Signaturen und MACs, IND-CCA2 für den gesamten JWE-Prozess bei Schlüsselmanagementverfahren sowie AEAD für Inhaltsverschlüsselung. Als Deprecated oder Prohibited beantragte Einträge wären davon ausgenommen.

Das Register sieht jedoch nicht, ob ein Dienst none für eine alte Objektklasse einschaltet oder ein Partner noch RSA1_5 verlangt. Der Entwurf definiert weder Telemetrie noch Ausnahmenverzeichnis noch Migrationsprotokoll. Nach Aussage des Shepherds entsteht überhaupt kein neuer Protokollmechanismus.

Diese Daten gehören auch nicht in ein zentrales Register. Nur die Anwendung kennt ihr Objekt, den Partner und die Folgen eines Bruchs. Lokal darf aber nicht formlos bedeuten.

Ein Ausnahmenachweis sollte Algorithmus, JWS- oder JWE-Nutzung, Objekt oder Vorgang, Dienst, verantwortliche Person, blockierende Abhängigkeit, kompensierende Kontrollen, den Test der globalen Deaktivierung, erste und letzte beobachtete Nutzung, Migrationsziel, Prüftermin und Ablauf enthalten. Das ist meine redaktionelle Empfehlung, keine Vorgabe des Entwurfs, von RFC 7518, IANA, NIST oder OpenID Connect.

Die öffentliche und die lokale Uhr

Die öffentliche Uhr umfasst Area-Director-Prüfung, möglichen IETF Last Call, IESG-Bewertung, eventuelle RFC-Veröffentlichung und IANA-Aktualisierung. Die Zusammenfassung im Datatracker nennt noch Internet Standard, während der Shepherd Proposed Standard beantragt und die frühere Metadatenangabe als falsch bezeichnet. Das ist eine offene Inkonsistenz im Datensatz, kein Endergebnis.

Die lokale Uhr startet mit der bewussten Reaktivierung. Ohne Ablaufdatum überlebt der „besondere Bedarf“ seine Abhängigkeit. Ohne Letztnutzung bleibt unklar, ob echte Kompatibilität oder nur ein vergessenes Schalterchen geschützt wird. Ohne Eigentümer erzwingt das nächste Bibliotheksupdate die Wahl zwischen Ausfall und zu breiter Freigabe.

Heng Lus Minimum Initial Specification setzt die gemeinsame Regel klein und lässt spätere Entscheidungen lokal. Seine Running-Code Primacy trennt Veröffentlichung von Betrieb: Konfiguration und beobachtete Vorgänge zeigen, welcher Pfad tatsächlich offen ist.

Der Entwurf verteilt die Zuständigkeit sinnvoll. Damit diese Ordnung hält, muss jede lokale Ausnahme benannt, eng, messbar und endlich sein.

Quellen

  1. IETF Datatracker — Abwertung von none und RSA1_5
  2. Datatracker-Verlauf und Shepherd-Bericht
  3. Internet-Draft Revision 05
  4. RFC 7518 — JSON Web Algorithms
  5. IANA — JOSE-Register
  6. RFC 5116 — Authenticated Encryption
  7. RFC 8017 — PKCS #1 Version 2.2
  8. NIST SP 800-131A Revision 2
  9. OpenID Connect Core 1.0
  10. Quellrepository des Entwurfs
  11. Heng Lu — Minimum Initial Specification
  12. Heng Lu — Running-Code Primacy