Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9864.¶

Copyright Notice

Copyright (c) 2025 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

The IANA algorithm registries for JSON Object Signing and Encryption (JOSE) algorithms [IANA.JOSE] and CBOR Object Signing and Encryption (COSE) algorithms [IANA.COSE] contain two kinds of algorithm identifiers:¶

Fully Specified

Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions. Examples are RS256 and ES256K in both JOSE [IANA.JOSE] and COSE [IANA.COSE] and ES256 in JOSE.¶

Polymorphic

Those requiring information beyond the algorithm identifier to determine the cryptographic operations to be performed. Such additional information could include the actual key value and a curve that it uses. Examples are the Edwards-curve Digital Signature Algorithm (EdDSA) in both JOSE [IANA.JOSE] and COSE [IANA.COSE] and ES256 in COSE.¶

This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata [RFC8414] uses negotiation parameters like these (from an example in that specification):¶

  "token_endpoint_auth_signing_alg_values_supported":
    ["RS256", "ES256"]

OpenID Connect Discovery [OpenID.Discovery] likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication [WebAuthn] and the FIDO Client to Authenticator Protocol (CTAP) [FIDO2] negotiate using COSE alg numbers.¶

This does not work for polymorphic algorithms. For instance, with EdDSA, it is not known which of the curves Ed25519 and/or Ed448 are supported. This causes real problems in practice.¶

WebAuthn contains this de facto algorithm definition to work around this problem:¶

  -8 (EdDSA), where crv is 6 (Ed25519)

This redefines the COSE EdDSA algorithm identifier for the purposes of WebAuthn to restrict it to using the Ed25519 curve -- making it non-polymorphic so that algorithm negotiation can succeed, but also effectively eliminating the possibility of using Ed448. Other similar workarounds for polymorphic algorithm identifiers are used in practice.¶

Note that using fully specified algorithms is sometimes referred to as the "cipher suite" approach; using polymorphic algorithms is sometimes referred to as the "à la carte" approach.¶

This specification creates fully specified algorithm identifiers for registered polymorphic JOSE and COSE algorithms and their parameters, enabling applications to use only fully specified algorithm identifiers. Furthermore, it deprecates the practice of registering polymorphic algorithm identifiers.¶

2. Fully Specified Digital Signature Algorithm Identifiers

This section creates fully specified digital signature algorithm identifiers for a set of registered polymorphic JOSE and COSE algorithms and their parameters.¶

3. Fully Specified Encryption

This section describes the construction of fully specified encryption algorithm identifiers in the context of the JOSE and COSE encryption schemes JSON Web Encryption (JWE), as described in [RFC7516] and [RFC7518], and COSE Encrypt, as described in [RFC9052] and [RFC9053].¶

Using fully specified encryption algorithms enables the sender and receiver to agree on all mandatory security parameters. They also enable protocols to specify an allow list of algorithm combinations that does not include polymorphic combinations, preventing problems such as cross-curve key establishment, cross-protocol symmetric encryption, or mismatched KDF size to symmetric key scenarios.¶

Both JOSE and COSE have operations that take multiple algorithms as parameters. Encrypted objects in JOSE [RFC7516] use two algorithm identifiers: the first in the "alg" (Algorithm) Header Parameter, which specifies how to determine the content encryption key, and the second in the "enc" (Encryption Algorithm) Header Parameter, which specifies the content encryption algorithm. Likewise, encrypted COSE objects can use multiple algorithms for corresponding purposes. This section describes how to fully specify encryption algorithms for JOSE and COSE.¶

To perform fully specified encryption in JOSE, the "alg" value MUST specify all parameters for key establishment or derive some of them from the accompanying "enc" value, and the "enc" value MUST specify all parameters for symmetric encryption. For example, encryption via JWE using an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) and an "enc" value of "A128GCM" (AES GCM using 128-bit key) uses fully specified algorithms.¶

Note that in JOSE, there is the option to derive some cryptographic parameters used in the "alg" computation from the accompanying "enc" value. For example, the keydatalen KDF parameter value for "ECDH-ES" is determined from the "enc" value, as described in Section 4.6.2 of [RFC7518]. For the purposes of an "alg" value being fully specified, deriving parameters from "enc" does not make the algorithm polymorphic, as the computation is still fully determined by the algorithm identifiers used. This option is not present in COSE.¶

To perform fully specified encryption in COSE, the outer "alg" value MUST specify all parameters for key establishment, and the inner "alg" value must specify all parameters for symmetric encryption. For example, encryption via COSE using an outer "alg" value of "A128KW" and an inner "alg" value of "A128GCM" uses fully specified algorithms. Note that when using COSE_Encrypt, as specified in Section 5.1 of [RFC9052], the outer "alg" is communicated in the headers of the COSE_Encrypt object and the inner "alg" is communicated in the headers of the COSE_recipient object.¶

While this specification provides a definition of what fully specified encryption algorithm identifiers are for both JOSE and COSE, it does not deprecate any polymorphic encryption algorithms, since replacements for them are not provided by this specification. This is discussed in Section 6.2.¶

4. IANA Considerations

5. Key Representations

The key representations for the new fully specified algorithms defined by this specification are the same as those for the polymorphic algorithms that they replace, other than the alg value, if included. For instance, the representation for a key used with the Ed25519 algorithm is the same as that specified in [RFC8037], except that the alg value would be Ed25519 rather than EdDSA, if included.¶

6. Notes on Algorithms Not Updated

Some existing polymorphic algorithms are not updated by this specification. This section discusses why they have not been updated.¶

7. Security Considerations

The security considerations for ECDSA in [RFC7518], for EdDSA in [RFC8037], and for ECDSA and EdDSA in [RFC9053] apply.¶

The security considerations for preventing cross-protocol attacks described in [RFC9459] apply.¶

An "attack signature" is a unique pattern or characteristic used to identify malicious activity, enabling systems to detect and respond to known threats. The digital signature and key establishment algorithms used by software can contribute to an attack signature. By varying the identifier used for an algorithm, some software systems may attempt to evade rule-based detection and classification. Rule-based detection and classification systems may need to update their rules to account for fully specified algorithms. These systems should be aware that writing rules for polymorphic algorithms is more difficult, as each variant of the algorithm must be accounted for. For example, ES384 in COSE might be used with three different keys, each with a different curve.¶

A cryptographic key MUST be used with only a single algorithm unless the use of the same key with different algorithms is proven secure. See [Reuse25519] for an example of such a proof. As a result, it is RECOMMENDED that the algorithm parameter of JSON Web Keys and COSE Keys be present, unless there exists some other mechanism for ensuring that the key is used as intended.¶

In COSE, preventing cross-protocol attacks, such as those described in [RFC9459], can be accomplished in two ways:¶

1. Allow only authenticated content encryption (Authenticated Encryption with Associated Data (AEAD)) algorithms.¶

2. Bind the potentially unauthenticated content encryption algorithm to be used to the key protection algorithm so that different content encryption algorithms result in different content encryption keys.¶

Which choice to use in which circumstances is beyond the scope of this specification.¶

Acknowledgements

The authors thank Mike Bishop, Carsten Bormann, Mohamed Boucadair, John Bradley, Tim Bray, Brian Campbell, Deb Cooley, Roman Danyliw, Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil Madden, Kathleen Moriarty, Jeremy O'Donoghue, John Preuß Mattsson, Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes Tschofenig, Sean Turner, Éric Vyncke, David Waite, Paul Wouters, and Jiankang Yao for their contributions to this specification.¶

Authors' Addresses