JOSE: Deprecate 'none' and 'RSA1_5'

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 May 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

JSON Web Algorithms (JWA) [RFC7518] introduced several standard algorithms for both JSON Web Signature (JWS) and JSON Web Encryption (JWE). Many of these algorithms have stood the test of time and are still in widespread use. However, some algorithms have proved to be difficult to implement correctly leading to exploitable vulnerabilities. This document deprecates two such algorithms:¶

• The JWS "none" algorithm, which indicates that no security is applied to the message at all.¶

• The JWE "RSA1_5" algorithm, which indicates RSA encryption using PKCS#1 version 1.5 (RSAES-PKCS1-v1_5 in [RFC8017]).¶

RSA signatures using PKCS#1 version 1.5 padding ("RS256", "RS384", and "RS512") are unchanged by this specification and can still be used.¶

This document updates [RFC7518]: it changes the implementation requirements of two algorithms (Section 8.1) and adds to the review instructions for the JOSE Designated Experts (Section 8.2). It updates the review instructions (Section 7 of [RFC7518]), to establish baseline security requirements for future JOSE algorithm registrations. Only algorithms that are reasonably assessed to satisfy these requirements are expected to be registered in the future. It also updates the implementations requirements of [RFC7519] to no longer require either algorithm (Section 6).¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terms defined in Section 2 of [RFC7515].¶

3. The 'none' algorithm

The "none" algorithm creates an Unsecured JWS, whose contents are completely unsecured as the name implies. Despite strong guidance in Section 3.6 of [RFC7518] to not accepting Unsecured JWS by default, many implementations have had serious bugs due to accepting this algorithm. In some cases, this has led to a complete loss of security as authenticity and integrity checking can be disabled by an adversary simply by changing the algorithm ("alg") header in the JWS. For example, [howmanydays] tracks public vulnerabilities due to implementations mistakenly accepting the "none" algorithm. As of October 2026 it lists 19 reports, many of which have high or critical impact ratings.¶

Although there are some historical uses for Unsecured JWS that are not security vulnerabilities, these are relatively few and can easily be satisfied by alternative means. For example, two of these are in OpenID Connect [OpenID.Core]: (1) securing unsigned ID Tokens (as allowed in Section 2) via transmission over TLS in Section 3.1.3.7 and (2) the use of unsigned request objects in Section 6.1. The small risk of breaking some of these uses is far outweighed by the improvement in security for the majority of JWS users who may be impacted by accidental acceptance of the "none" algorithm.¶

4. The 'RSA1_5' algorithm

The "RSA1_5" algorithm implements RSA encryption using PKCS#1 version 1.5 padding (Section 7.2 of [RFC8017]). This padding mode has long been known to have security issues, since at least Bleichenbacher's attack ([RFC3218]) in 1998. It was supported in JWE due to the wide deployment of this algorithm, especially in legacy hardware. However, more secure replacements such as OAEP [RFC8017] or elliptic curve encryption algorithms are widely available since then. US National Institute of Standards and Technology (NIST) has disallowed the use of this encryption mode for federal use since the end of 2023 [NIST.SP800-131Ar2] and a CFRG document [I-D.irtf-cfrg-rsa-guidance] also deprecates this encryption mode for new protocols and deployments. This document therefore also deprecates this algorithm for JWE.¶

5. Guidance on Deprecation

Both of the algorithms listed above are deprecated for use in JOSE: the "none" algorithm for JWS, and "RSA1_5" for JWE. JOSE library developers should deprecate support for these algorithms and should not enable them by default. Application developers must disable support for these algorithms by default. Consistent with the existing requirement in Section 3.6 of [RFC7518] that implementations "MUST NOT accept Unsecured JWSs by default", an application that has a specific need for one of these algorithms may enable it, but only for the specific objects or operations that require it and not at a global level. New specifications building on top of JOSE, including revisions of existing specifications, must not allow the use of either algorithm, including for the uses of "none" described in Section 3.2 of [I-D.ietf-oauth-rfc8725bis].¶

The IANA algorithm registry distinguishes between algorithms that are "Deprecated" and those that are "Prohibited" (Section 4.4 of [RFC9864]). The algorithms identified in this document are to be marked as Deprecated only; the requirements in this section apply in addition to that definition. Existing specifications and applications that make use of these algorithms can continue to do so, but are encouraged to adopt alternatives in future updates.¶

6. Updated Implementation Requirements for JSON Web Token

Section 8 of [RFC7519] (JWT) says that '"none" MUST be implemented by conforming JWT implementations', and that "RSA1_5" must be implemented by JWT implementations providing encryption capabilities. This document updates [RFC7519] to remove both requirements: "none" and "RSA1_5" are no longer mandatory to implement for conforming JWT implementations. JWT implementors should deprecate support for both algorithms as described in Section 3.2 of [I-D.ietf-oauth-rfc8725bis].¶

7. Security Considerations

This entire document is concerned with security, since the security of JOSE implementations directly affects the security of systems that include them (see for example the referenced vulnerabilities in Section 3).¶

Both algorithms remain registered, and Section 5 permits an application to enable either of them for specific objects or operations. Wherever they are enabled, the exposures described in Section 3 and Section 4 remain; see Sections 8.3 and 8.5 of [RFC7518] and Sections 11.4 and 11.5 of [RFC7516] for existing considerations and mitigations.¶

8. IANA Considerations

9. References

Appendix A. Acknowledgments

The author would like to thank the following people for feedback and useful suggestions: Mike Ounsworth, Michael B. Jones, Yaron Sheffer, Brian Campbell, Aaron Parecki, Filip Skokan, Tim Bray, John Mattsson, Deb Cooley, Karen O'Donoghue, and Barry Leiba.¶

Author's Address