Summary

  • Revision 06 would mark JWS none and JWE RSA1_5 as Deprecated, not Prohibited; existing applications may retain narrowly scoped use while new JOSE specifications must not allow either algorithm.
  • The live IANA registry had not yet applied that change on 29 September 2026, and even a future registry update would not prove that a library removed capability or that an application rejected a particular object.
  • The useful retirement receipt follows the decision through application default, object or operation exception, effective library capability, presented algorithm and observed accept or reject result.

One word in a registry can make a security programme look finished.

Deprecated sounds like the algorithm is already behind glass. A dependency scanner turns green. An inventory shows a new library. A governance slide says the standard has moved on. Then an old partner sends a token, a compatibility switch opens, and the runtime says yes.

Revision 06 of “JOSE: Deprecate 'none' and 'RSA1_5'” makes that gap unusually explicit. Posted on 25 September 2026, the Datatracker record places it in IETF Last Call through 9 October with IANA review still needed. It is an Internet-Draft, not an RFC or evidence that a registry, library or service has changed. Its history records document movement, not deployment.

The draft addresses two different mechanisms. JWS none creates an Unsecured JWS: no signature and no MAC. RFC 7515 defines the signed-object framework; RFC 7518 already said implementations must not accept unsecured JWS by default. Yet repeated failures occurred when software allowed an input-controlled alg value to turn authenticity checking off.

JWE RSA1_5 is not the same thing. It is a key-management algorithm using RSAES-PKCS1-v1_5 inside the encrypted-object model of RFC 7516. Adaptive chosen-ciphertext attacks have followed that padding family since Bleichenbacher's work. RFC 8017 specifies the underlying RSA schemes, while the current CFRG RSA guidance treats failure handling and oracle resistance as implementation concerns, not properties conferred by a name.

The distinction matters because the draft does not deprecate RS256, RS384 or RS512. Those are RSA signature algorithms using PKCS#1 v1.5 signature padding. RSA1_5 is the JWE key-encryption identifier. A control that blocks every label containing “RSA” would break unrelated operations while proving little about the vulnerable path.

The proposed transition has four different verbs. Library developers should deprecate support. Application developers must disable both choices by default. An application with a specific need may enable one for the particular objects or operations that require it, but not globally. New specifications building on JOSE must not allow either one.

That is not deletion. The draft deliberately asks IANA for Deprecated, not Prohibited. Existing specifications and applications can continue, though they are encouraged to migrate. At capture time, the live IANA JOSE registry still showed none as Optional and RSA1_5 as Recommended-. The proposed registry change, if it occurs, will alter shared metadata. It will not reach into each tenant, gateway, SDK, hardware module or exception file.

The evidence chain therefore starts after the label. Record the JOSE object class and business operation; the protected alg and, for JWE, enc; the issuer, audience, tenant and route policy; the application allow-list after those selectors are resolved; the library version and actual compiled capability; the source, owner, scope and expiry of any exception; the key type selected; the final accept or reject result; and the principal or action that result authorised.

For JWE, failure shape belongs in the same record. Different errors, response sizes or timings can turn a decryption endpoint into an oracle even when a dashboard says RSA1_5 is exceptional. NIST SP 800-131A Revision 2 supplies transition context, not a local proof that every error path is uniform.

RFC 8725 tells JWT implementations to perform algorithm verification and avoid relying on attacker-controlled choices. That principle still needs an effective allow-list at the application boundary. The token header is a claim about requested processing; it is not authority to select the verifier.

The draft also changes the future registry gate. New JWS signature and MAC algorithms should satisfy EUF-CMA; the complete JWE encryption process should satisfy IND-CCA2; content encryption should provide AEAD as described by RFC 5116. These are useful review baselines. They are not test results for a concrete build, nor do they absolve composition errors around keys, parsing and policy.

Heng Lu's running-code primacy puts the acceptance event above the inventory label. Reality layers separate a symbolic deprecation from the operational fact that a message obtained authority. Minimum initial specification explains why the shared rule can set a safe default while a local system remains accountable for a narrow exception.

The retirement is complete only when relevant runtime paths reject both algorithms by default and every remaining yes is specific, attributed, measured and expiring. Until then, Deprecated is a warning at the entrance—not a receipt from the decision point.

Sources