Summary

  • On 6 September, the JOSE Working Group sent its draft deprecating none and RSA1_5 to the IESG with publication requested. That is a standards-process handoff, not approval, an RFC or an implemented registry change.
  • The draft would make the algorithms off by default and unavailable to new JOSE specifications, while still permitting an application to enable one for specific objects or operations. That local exception needs an owner, scope, review date and expiry if deprecation is to become observable migration rather than a permanent label.

Four rules, not one ban

The important word in draft-ietf-jose-deprecate-none-rsa15-05 is not simply “deprecate.” It is the distribution of responsibility around that word.

On 6 September 2026, the Datatracker recorded that the JOSE Working Group had submitted revision 05 to the IESG for publication. The IESG state became “Publication Requested,” and Deb Cooley was named responsible Area Director. The document remains an Internet-Draft. It has not been approved by the IESG, published as an RFC or applied to the live IANA registry.

If approved, the draft would update RFC 7518 and assign four different instructions to four different surfaces.

JOSE library developers SHOULD deprecate support for the JWS algorithm none and the JWE key-management algorithm RSA1_5. Application developers MUST disable them by default. An application with a specific need MAY enable one only for the particular objects or operations that require it, not through a global switch. New specifications built on JOSE MUST NOT allow either algorithm.

That is not a universal ban. The draft expressly chooses the IANA status Deprecated rather than Prohibited. It says existing specifications and applications can continue to use the algorithms, while encouraging alternatives in future updates. It also states that RSA signature identifiers RS256, RS384 and RS512 are not changed; RSA1_5 here names RSAES-PKCS1-v1_5 key management for JWE.

Those distinctions matter operationally. “The standard deprecated it,” “the library still implements it,” “the application enables it for one object class,” and “a live transaction accepted it” are four different facts. Compressing them into a single compliance badge would hide the very exception boundary the draft tries to preserve.

Why the exception exists

The document's security case is direct. none creates an Unsecured JWS: no signature or MAC protects the content. RFC 7518 already said implementations must not accept Unsecured JWS by default, yet the new draft recounts repeated vulnerabilities in which implementations mistakenly accepted it. For RSA1_5, the concern is RSA encryption with PKCS #1 v1.5 padding, whose weaknesses have been known since Bleichenbacher's 1998 attack. The draft points to OAEP and elliptic-curve approaches as alternatives and cites NIST's federal transition guidance.

But compatibility is real too. The draft acknowledges historical OpenID Connect uses of unsigned ID Tokens carried over TLS and unsigned request objects. According to the shepherd write-up, that language followed discussion at IETF 124 and a two-week consensus call in February 2026. The compromise recognized the historical cases without abandoning deprecation.

The Working Group record is stronger than silence but narrower than universal assent. The shepherd reports support and no opposition during an extended Working Group Last Call. A poll at IETF 126 recorded 27 participants supporting publication, none opposing and eight expressing no opinion. Those figures support the process judgment that the draft can advance. They do not count implementations, users or local dependencies.

A registry label cannot enumerate runtime exceptions

At the evidence cutoff, the IANA JOSE registry still showed none as Optional and RSA1_5 as Recommended-. That is the expected public state while the proposal remains unfinished; it is not evidence of delay or resistance. If the draft becomes an RFC and IANA executes its instructions, the central record can tell everyone that the common recommendation changed.

The central record cannot tell an operator whether a particular service has turned either algorithm back on. The draft does not define a telemetry channel, an exception database or a migration protocol. The shepherd explicitly says it creates no new protocol mechanism requiring implementation.

That omission is not a mandate to make IANA a deployment regulator. An algorithm registry should identify the interoperable meaning and recommendation status of an identifier. It should not receive the names of private applications, protected object classes or internal compatibility dependencies.

The operational evidence belongs closer to the decision. When an application enables a deprecated algorithm, a local exception record should bind at least:

  • the exact algorithm and whether it is used for JWS or JWE;
  • the object type or operation for which it is enabled;
  • the service and accountable owner;
  • the dependency that prevents immediate removal;
  • compensating controls and the proof that the global default remains off;
  • first-seen and most-recent-use observations;
  • the replacement path, review date and expiry;
  • the evidence required to renew or close the exception.

This is an editorial recommendation, not text required by the draft, RFC 7518, IANA, NIST or OpenID Connect. Its purpose is to make the draft's own narrow exception boundary testable without centralizing the decision.

Deprecation needs two clocks

The first clock is public. It runs from Working Group submission through IESG review, possible approval, RFC publication and an IANA registry update. Every stage has a distinct authority. The current Datatracker summary still displays an Internet Standard intention, while the shepherd says Proposed Standard is requested and identifies the former metadata as incorrect. That mismatch should be read as an unresolved public-record detail, not as a final status or a process failure.

The second clock is local. It begins when an application deliberately enables a deprecated algorithm for a bounded purpose. Without an expiry, “specific need” can survive after the dependency disappears. Without last-used evidence, teams cannot distinguish an active compatibility requirement from a switch nobody dares to remove. Without an owner, a library upgrade can either break a hidden workflow or preserve a global escape hatch indefinitely.

Heng Lu's argument for a minimum initial specification offers a useful boundary here. The common layer should be small and deterministic; later choices can remain local. His running-code primacy supplies the evidentiary test: publication changes the rulebook, while configuration and observed transactions show what actually runs.

The draft largely gets the allocation of authority right. It makes the safe default common, forbids new specifications from reopening the path, and leaves legacy exceptions with the applications that understand them. The next task is not thicker central governance. It is an expiring local record that proves the exception remains narrow.

Sources

  1. IETF Datatracker — JOSE: Deprecate none and RSA1_5
  2. Datatracker history and document shepherd write-up
  3. Internet-Draft revision 05
  4. RFC 7518 — JSON Web Algorithms
  5. IANA — JSON Object Signing and Encryption registry
  6. RFC 5116 — Authenticated Encryption interface
  7. RFC 8017 — PKCS #1 version 2.2
  8. NIST SP 800-131A Revision 2
  9. OpenID Connect Core 1.0
  10. Draft source repository
  11. Heng Lu — Minimum Initial Specification
  12. Heng Lu — Running-Code Primacy