Summary

  • IETF Last Call on draft-ietf-jose-deprecate-none-rsa15-06 runs to 9 October 2026; the document remains a draft and has not changed the live IANA registry.
  • The draft would ask JOSE Designated Experts to apply EUF-CMA to JWS signatures and MACs, IND-CCA2 to the entire JWE encryption process for key-management registrations, and AEAD to JWE content-encryption methods.
  • Those criteria make the shared review charter more precise. They do not certify a library, composition, key, configuration, rollout or production exchange.

The quieter half of the Last Call

On 25 September, the IESG opened Last Call on a JOSE draft whose title points to the proposed deprecation of none and RSA1_5. Comments are due by 9 October. The Datatracker correctly describes the document as work in progress, aimed at Proposed Standard, with IANA review still needed.

The backward-looking changes are prominent because they name familiar failure histories. The forward-looking change is smaller on the page and potentially more durable. Section 7.2 would update the instructions used by the Designated Experts who review additions to the IANA JSON Web Signature and Encryption Algorithms registry.

Today, RFC 7518 gives those reviewers a broad duty. A proposed registration should not duplicate existing functionality without reason, should have general applicability, should be clearly described and should survive reasonable due diligence about cryptographic credibility. The registration procedure is Specification Required, with a public review period and a decision communicated to IANA.

The draft would not replace that machinery. It would place three named security goals inside it. That changes the question from “does this appear cryptographically credible?” to “credible against which attack model, for which role, and at what system boundary?”

Three roles, three security goals

For JWS signature and MAC algorithms, the proposed test is existential unforgeability under a chosen-message attack, or EUF-CMA. In practical terms, an adversary who can obtain valid authenticators for chosen messages should still not be able to produce a valid authenticator for a new message. The criterion fits the job: a signature or MAC registration is useful only if the authenticity claim resists forgery under a stated model.

For JWE content-encryption methods, the proposed goal is authenticated encryption with associated data, or AEAD. JWE needs confidentiality for the plaintext and integrity for information that may remain visible but must not be altered unnoticed. RFC 5116 explains the separation: associated data is authenticated without being encrypted. A content-encryption registration therefore needs more than secrecy; it must preserve the binding between protected content and the context that travels beside it.

The key-management criterion is the revealing one. The draft asks whether the resulting JWE encryption process as a whole is reasonably believed to achieve indistinguishability under an adaptive chosen-ciphertext attack, or IND-CCA2. It explicitly refuses to judge the key-management algorithm in isolation.

That phrase prevents a common evidence error. A strong primitive can sit inside a weak composition. Parameters can be bound incorrectly. Error behavior can reveal distinctions. The content-encryption choice can undermine the claim. Negotiation, serialization or key handling can create an attack surface that the isolated key-wrapping operation never sees. If the promised property belongs to the composed JWE process, the review evidence must cross component boundaries too.

A better charter is still a judgment

The draft uses the words “reasonably believed.” It does not demand one universal proof format, a particular laboratory report or a mechanical checklist. The Designated Expert still coordinates judgment, can consult specialists and must apply the documented charter to the material available.

That is not a defect hidden in the wording. Algorithm registration joins formal results, public analysis, specification quality and engineering context. Some constructions have reductions; some rely on mature external review; some combine components whose interaction must be argued. A registry procedure cannot turn all of that into a Boolean test without losing relevant evidence.

Named goals nevertheless improve accountability. An applicant and reviewer can now dispute whether the claimed construction meets EUF-CMA, whether the JWE analysis actually covers the whole encryption process, or whether an enc method supplies AEAD. The disagreement becomes narrower and more reviewable than an appeal to undifferentiated “soundness.”

The exemption also matters. The new criteria would not apply when an algorithm is registered as Deprecated or Prohibited. The registry is partly a coordination and historical identification surface. It must be able to name an algorithm that should not be selected for ordinary use. Presence in the table therefore cannot mean approval in the consumer sense.

The live registry has not moved

Last Call is not publication, and publication is not an IANA update until the approved instructions are executed. At the frozen retrieval, the live registry still showed its current entries and implementation-requirement labels. The draft's proposed changes were not operational facts merely because the IESG invited comments.

This temporal distinction is essential for audit. A security team should preserve the draft revision, the Last Call notice, the eventual RFC if one appears, the IANA change record and the registry snapshot used by its software. Reconstructing only the latest page can erase which rule governed an earlier decision.

The same discipline applies after a registration. A registry row can establish an identifier, usage location, implementation-requirement label, change controller, specification reference and analysis references. It cannot establish which library version shipped the code, whether that code matches the reviewed construction, which parameters were enabled, where keys came from, whether downgrade was blocked or whether an actual exchange achieved the intended property.

The thin common layer and the running system

Heng Lu's Minimum Initial Specification offers a useful disclosed editorial lens. Shared security invariants belong in the common layer when independent implementations need the same baseline to interoperate safely. EUF-CMA, whole-process IND-CCA2 and AEAD are intelligible candidates for such a floor. They are narrower than a committee's preference for a vendor, architecture or deployment timetable.

The other half of that discipline is equally important: publication must not be mistaken for adoption, and registration must not be mistaken for running reality. The registry coordinates names and review claims. Implementers still write and test code. Operators still choose allowed algorithms, provision keys, constrain negotiation, observe failures and decide when to withdraw a capability. Relying parties still decide what evidence they need before trusting a particular service.

The draft is strongest where it recognizes composition. Its whole-process JWE language points beyond the comfort of checking a primitive and invites evidence at the boundary where components meet. Leadership should preserve that insight downstream. An algorithm approval record, an implementation conformance record, a deployment authorization and a transaction receipt are four different objects. Combining them into one green badge would undo the clarity the draft is trying to create.

Sources