RFC 9864

Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)

📅 published October 2025, from ietf

RFC 9864 ✨ Fully-Specified Algorithms for JOSE and COSE 🎀

okay bestie, this one is about making crypto algorithm names fully explicit so nobody has to guess 🔥 it's Standards Track (so it's an official Internet standard, no cap 💅), published October 2025 🍓

Authors: M.B. Jones (Self-Issued Consulting) and O. Steele (Tradeverifyd) 🫶

What it does to older RFCs: it updates RFC 7518, RFC 8037, and RFC 9053 💖 (so those three are getting a glow-up, not replaced 🦋). It doesn't obsolete anything.

The vibe in one sentence: a bunch of algorithm names only say part of the story (like "EdDSA" without saying which curve 👀), so this doc makes fully-specified versions for them and deprecates the vague "polymorphic" ones 🌈 Let's get into it ✨

Abstract 🌸

okay so the abstract is basically the TL;DR 💅 an algorithm ID is fully specified if it pins down everything the crypto needs: the curve, the KDF, the hash, all of it 🧚 an ID is polymorphic if you still need extra info (like the actual key) to figure out what operation will happen 👀

this spec makes fully-specified IDs for the registered polymorphic JOSE and COSE algorithms, so apps can use only the fully-specified ones 🎀 and it deprecates the polymorphic ones 😭

it also updates RFC 7518, 8037, and 9053. it deprecates the polymorphic algorithms defined in RFC 8037 and 9053 and gives fully-specified replacements for them 💜 and it adds stuff to the designated expert instructions in RFC 7518 and 9053 🙈

Status of This Memo 🦋

this is an Internet Standards Track document 💖 it's a product of the IETF and it represents the consensus of the IETF community. it got public review and was approved by the IESG ✨ if you want more on Internet Standards, check out Section 2 of RFC 7841 🧚

all the current status info, errata, and feedback stuff lives at https://www.rfc-editor.org/info/rfc9864 🌈

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 🫶 read those carefully because they're about your rights and restrictions 👀

if you extract Code Components from this doc, they have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 🔥

Table of Contents 🌸

okay the TOC is just the map 🗺️ here's the full structure, copied exactly:

1.  Introduction
  1.1.  Requirements Notation and Conventions
2.  Fully-Specified Digital Signature Algorithm Identifiers
  2.1.  Elliptic Curve Digital Signature Algorithm (ECDSA)
  2.2.  Edwards-curve Digital Signature Algorithm (EdDSA)
3.  Fully-Specified Encryption
  3.1.  Fully-Specified Encryption Algorithms
  3.2.  Polymorphic Encryption Algorithms
4.  IANA Considerations
  4.1.  JOSE Algorithm Registrations
    4.1.1.  Fully-Specified JOSE Algorithm Registrations
    4.1.2.  Deprecated Polymorphic JOSE Algorithm Registration
  4.2.  COSE Algorithm Registrations
    4.2.1.  Fully-Specified COSE Algorithm Registrations
    4.2.2.  Deprecated Polymorphic COSE Algorithm Registrations
  4.3.  Updated Review Instructions for Designated Experts
    4.3.1.  JSON Web Signature and Encryption Algorithms
    4.3.2.  COSE Algorithms
  4.4.  Defining "Deprecated" and "Prohibited"
5.  Key Representations
6.  Notes on Algorithms Not Updated
  6.1.  RSA Signing Algorithms
  6.2.  ECDH Key Agreement Algorithms
  6.3.  HSS/LMS Hash-Based Digital Signature Algorithm
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so the IANA registries for JOSE algorithms [IANA.JOSE] and COSE algorithms [IANA.COSE] have two kinds of IDs 🎀

Fully Specified 💅 these fully determine the operations, including the curve, KDF, and hash functions. examples are RS256 and ES256K (in both JOSE and COSE) and ES256 in JOSE 🌸

Polymorphic 🦋 these need extra info beyond the ID to figure out the operations. that extra info could be the actual key value and the curve it uses 👀 examples are EdDSA (in both JOSE and COSE) and ES256 in COSE 🙈

this matters a LOT because lots of protocols negotiate what they support using just the algorithm IDs 😭 for example, OAuth Authorization Server Metadata [RFC8414] uses things like this (from an example in that spec):

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

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

but polymorphic stuff breaks this 💀 with EdDSA, you don't know whether Ed25519 and/or Ed448 are supported, and that causes real problems in practice 😭

WebAuthn came up with a de facto workaround for this:

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

so it redefines the COSE EdDSA ID for WebAuthn to only use Ed25519 🌈 that makes it non-polymorphic so negotiation can work, but it also effectively rules out Ed448 🥺 other similar workarounds for polymorphic IDs are used in practice too ✨

quick vocab moment: using fully-specified algorithms is sometimes called the "cipher suite" approach, and using polymorphic ones is sometimes called the "à la carte" approach 💅🍓

so this spec makes fully-specified IDs for registered polymorphic JOSE and COSE algorithms and their parameters, so apps can use only fully-specified IDs 🎀 it also deprecates the practice of registering polymorphic IDs 🔥

1.1. Requirements Notation and Conventions 🌸

okay the BCP 14 key words (MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL) only mean their formal thing when they show up in ALL CAPS like that 🧚 they're interpreted as described in BCP 14 [RFC2119] [RFC8174] 💖

2. Fully-Specified Digital Signature Algorithm Identifiers 🦋

this section makes fully-specified digital signature algorithm IDs for a set of registered polymorphic JOSE and COSE algorithms and their parameters 💅

2.1. Elliptic Curve Digital Signature Algorithm (ECDSA) 💜

[RFC9053] shows how to use ECDSA with COSE 🌈 the COSE ECDSA registrations are polymorphic because they don't say which curve gets used 👀 for example, ES256 is "ECDSA w/ SHA-256" in Section 2.1 of [RFC9053] 🫶 (the matching JOSE registrations in [RFC7518] are already fully specified ✨)

these fully-specified COSE ECDSA algorithms are defined by this spec 🎀

+========+============+=============================+=============+
| Name   | COSE Value | Description                 | COSE        |
|        |            |                             | Recommended |
+========+============+=============================+=============+
| ESP256 | -9         | ECDSA using P-256 curve and | Yes         |
|        |            | SHA-256                     |             |
+--------+------------+-----------------------------+-------------+
| ESP384 | -51        | ECDSA using P-384 curve and | Yes         |
|        |            | SHA-384                     |             |
+--------+------------+-----------------------------+-------------+
| ESP512 | -52        | ECDSA using P-521 curve and | Yes         |
|        |            | SHA-512                     |             |
+--------+------------+-----------------------------+-------------+
| ESB256 | -265       | ECDSA using BrainpoolP256r1 | No          |
|        |            | curve and SHA-256           |             |
+--------+------------+-----------------------------+-------------+
| ESB320 | -266       | ECDSA using BrainpoolP320r1 | No          |
|        |            | curve and SHA-384           |             |
+--------+------------+-----------------------------+-------------+
| ESB384 | -267       | ECDSA using BrainpoolP384r1 | No          |
|        |            | curve and SHA-384           |             |
+--------+------------+-----------------------------+-------------+
| ESB512 | -268       | ECDSA using BrainpoolP512r1 | No          |
|        |            | curve and SHA-512           |             |
+--------+------------+-----------------------------+-------------+

Table 1: ECDSA Algorithm Values 🍓

2.2. Edwards-curve Digital Signature Algorithm (EdDSA) 🧚

[RFC8037] shows how to use EdDSA with JOSE 💖 and [RFC9053] shows how to use it with COSE 💜 both register polymorphic EdDSA IDs 😭

these fully-specified JOSE and COSE EdDSA algorithms are defined by this spec ✨

+=========+=======+================+================+=============+
| Name    | COSE  | Description    | JOSE           | COSE        |
|         | Value |                | Implementation | Recommended |
|         |       |                | Requirements   |             |
+=========+=======+================+================+=============+
| Ed25519 | -19   | EdDSA using    | Optional       | Yes         |
|         |       | the Ed25519    |                |             |
|         |       | parameter set  |                |             |
|         |       | in Section 5.1 |                |             |
|         |       | of [RFC8032]   |                |             |
+---------+-------+----------------+----------------+-------------+
| Ed448   | -53   | EdDSA using    | Optional       | Yes         |
|         |       | the Ed448      |                |             |
|         |       | parameter set  |                |             |
|         |       | in Section 5.2 |                |             |
|         |       | of [RFC8032]   |                |             |
+---------+-------+----------------+----------------+-------------+

Table 2: EdDSA Algorithm Values 🌈

Part 1 of 4 ✨ the rest of the RFC is coming next, bestie 💅🫶

3. Fully-Specified Encryption 🎀

Okay bestie, this section is all about building fully-specified encryption algorithm identifiers for the JOSE and COSE encryption schemes. For JOSE that's JSON Web Encryption (JWE) from [RFC7516] and [RFC7518], and for COSE it's the encryption stuff from [RFC9052] and [RFC9053]. ✨

Fully-specified encryption lets the sender and receiver agree on every mandatory security parameter 💖. It also lets protocols write an allow list of algorithm combinations that leaves out the polymorphic ones, which blocks problems like cross-curve key establishment, cross-protocol symmetric encryption, and mismatched KDF size to symmetric key scenarios 💀. Absolutely not on my watch.

Both JOSE and COSE have operations that take more than one algorithm as a parameter 🧚. Encrypted JOSE objects [RFC7516] use two algorithm identifiers. The first is in the "alg" (Algorithm) Header Parameter, which says how to figure out the content encryption key. The second is in the "enc" (Encryption Algorithm) Header Parameter, which says which content encryption algorithm to use. Encrypted COSE objects can use multiple algorithms for matching purposes too, so this section explains how to fully specify encryption algorithms for both JOSE and COSE 🌈.

To do fully-specified encryption in JOSE, the "alg" value MUST specify all parameters for key establishment, or pull some of them from the "enc" value next to it. The "enc" value MUST specify all parameters for symmetric encryption. For example, JWE with an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) and an "enc" value of "A128GCM" (AES GCM using 128-bit key) is fully specified 👑.

Quick note, though: in JOSE you're allowed to derive some cryptographic parameters used in the "alg" computation from the "enc" value. For instance, 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, because the computation is still fully determined by the algorithm identifiers used. This option does not exist in COSE 🦋.

To do 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, COSE with an outer "alg" value of "A128KW" and an inner "alg" value of "A128GCM" is fully specified. When you use COSE_Encrypt, as specified in Section 5.1 of [RFC9052], the outer "alg" gets communicated in the headers of the COSE_Encrypt object, and the inner "alg" gets communicated in the headers of the COSE_recipient object 💅.

This spec defines what fully-specified encryption algorithm identifiers are for both JOSE and COSE, but it does not deprecate any polymorphic encryption algorithms. That's because this specification doesn't provide replacements for them. Section 6.2 talks about this more 🙈.

3.1. Fully-Specified Encryption Algorithms

Lots of the registered JOSE and COSE encryption algorithms are already fully specified, so this part covers those 🍓.

All the symmetric encryption algorithms registered by [RFC7518] and [RFC9053] are fully specified. An example of a fully-specified symmetric encryption algorithm is "A128GCM" (AES GCM using 128-bit key) 🌸.

In both JOSE and COSE, every registered key wrapping algorithm is fully specified, and so are the algorithms that do key wrapping using AES GCM. An example of a fully-specified key wrapping algorithm is "A128KW" (AES Key Wrap using 128-bit key) 🔐.

The JOSE "dir" algorithm and the COSE "direct" algorithm are fully specified. The COSE direct+HKDF algorithms are fully specified too ✨.

The JOSE algorithms that do Key Encryption with PBES2 are fully specified 💜.

3.2. Polymorphic Encryption Algorithms

Some of the registered JOSE and COSE encryption algorithms are polymorphic, and this part talks about those 🌀.

The Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms in both JOSE and COSE are polymorphic, because they don't specify which elliptic curve to use for the key. That's true of the ephemeral key for the Ephemeral-Static (ES) algorithms registered for JOSE and COSE, and of the static key for the Static-Static (SS) algorithms registered by COSE. Check out Section 6.2 for more on ECDH algorithms 🫶.

4. IANA Considerations 📋

4.1. JOSE Algorithm Registrations

IANA has registered the values in this section in the "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE], which was established by [RFC7518]. IANA also listed this document as an additional reference for that registry 🗂️.

4.1.1. Fully-Specified JOSE Algorithm Registrations

Here are the fully-specified JOSE ones 💖:

Algorithm Name:  Ed25519
Algorithm Description:  EdDSA using the Ed25519 parameter set in
   Section 5.1 of [RFC8032]
Algorithm Usage Locations:  alg
JOSE Implementation Requirements:  Optional
Change Controller:  IETF
Reference:  Section 2.2 of RFC 9864
Algorithm Analysis Document(s):  [RFC8032]
Algorithm Name:  Ed448
Algorithm Description:  EdDSA using the Ed448 parameter set in
   Section 5.2 of [RFC8032]
Algorithm Usage Locations:  alg
JOSE Implementation Requirements:  Optional
Change Controller:  IETF
Reference:  Section 2.2 of RFC 9864
Algorithm Analysis Document(s):  [RFC8032]

4.1.2. Deprecated Polymorphic JOSE Algorithm Registration

IANA has changed the status of the following registration to "Deprecated" 🥀.

Algorithm Name:  EdDSA
Algorithm Description:  EdDSA signature algorithms
Algorithm Usage Locations:  alg
JOSE Implementation Requirements:  Deprecated
Change Controller:  IETF
Reference:  Section 2.2 of RFC 9864
Algorithm Analysis Document(s):  [RFC8032]

4.2. COSE Algorithm Registrations

IANA registered the following values in the "COSE Algorithms" registry [IANA.COSE], which was established by [RFC9053] and [RFC9054]. IANA also added this document as an additional reference for the registry 🌷.

4.2.1. Fully-Specified COSE Algorithm Registrations

The fully-specified COSE ones are below. Look at all these shiny new values 🤩.

Name:  ESP256
Value:  -9
Description:  ECDSA using P-256 curve and SHA-256
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  Yes
Name:  ESP384
Value:  -51
Description:  ECDSA using P-384 curve and SHA-384
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  Yes
Name:  ESP512
Value:  -52
Description:  ECDSA using P-521 curve and SHA-512
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  Yes
Name:  ESB256
Value:  -265
Description:  ECDSA using BrainpoolP256r1 curve and SHA-256
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  No
Name:  ESB320
Value:  -266
Description:  ECDSA using BrainpoolP320r1 curve and SHA-384
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  No
Name:  ESB384
Value:  -267
Description:  ECDSA using BrainpoolP384r1 curve and SHA-384
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  No
Name:  ESB512
Value:  -268
Description:  ECDSA using BrainpoolP512r1 curve and SHA-512
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.1 of RFC 9864
Recommended:  No
Name:  Ed25519
Value:  -19
Description:  EdDSA using the Ed25519 parameter set in Section 5.1 of
   [RFC8032]
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.2 of RFC 9864
Recommended:  Yes
Name:  Ed448
Value:  -53
Description:  EdDSA using the Ed448 parameter set in Section 5.2 of
   [RFC8032]
Capabilities:  [kty]
Change Controller:  IETF
Reference:  Section 2.2 of RFC 9864
Recommended:  Yes

4.2.2. Deprecated Polymorphic COSE Algorithm Registrations

IANA changed the status of the following registrations to "Deprecated" and added this document as a reference for them 🍂.

Name:  ES256
Value:  -7
Description:  ECDSA w/ SHA-256
Capabilities:  [kty]
Change Controller:  IETF
Reference:  [RFC9053] and RFC 9864
Recommended:  Deprecated
Name:  ES384
Value:  -35
Description:  ECDSA w/ SHA-384
Capabilities:  [kty]
Change Controller:  IETF
Reference:  [RFC9053] and RFC 9864
Recommended:  Deprecated
Name:  ES512
Value:  -36
Description:  ECDSA w/ SHA-512
Capabilities:  [kty]
Change Controller:  IETF
Reference:  [RFC9053] and RFC 9864
Recommended:  Deprecated
Name:  EdDSA
Value:  -8
Description:  EdDSA
Capabilities:  [kty]
Change Controller:  IETF
Reference:  [RFC9053] and RFC 9864
Recommended:  Deprecated

4.3. Updated Review Instructions for Designated Experts

Okay, so the designated experts got some new homework 📝.

4.3.1. JSON Web Signature and Encryption Algorithms

The review instructions for the designated experts [RFC8126] for the "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE] in Section 7.1 of [RFC7518] have been updated to include an additional review criterion:

  • Only fully-specified algorithm identifiers may be registered. Polymorphic algorithm identifiers must not be registered.

4.3.2. COSE Algorithms

The review instructions for the designated experts [RFC8126] for the "COSE Algorithms" registry [IANA.COSE] in Section 10.4 of [RFC9053] have been updated to include an additional review criterion:

  • Only fully-specified algorithm identifiers may be registered. Polymorphic algorithm identifiers must not be registered.

4.4. Defining "Deprecated" and "Prohibited" ✨

okay so "Deprecated" and "Prohibited" are used all over JOSE and COSE registrations, but nobody actually defined them 😭 JOSE in [RFC7518] lets you use both, but COSE in [RFC8152] only lets you use "Deprecated" and not "Prohibited". (Side note: [RFC8152] got obsoleted by [RFC9052] 💅) This section finally pins them down for both JOSE and COSE so the whole thing is consistent and we stop getting that confusing mismatch 🫶

For use in the "JOSE Implementation Requirements" columns in the IANA JOSE registries [IANA.JOSE] and the "Recommended" columns in the IANA COSE registries [IANA.COSE], the terms mean this:

  • Deprecated: There is a preferred mechanism to get functionality similar to what the identifier references, and this replacement functionality SHOULD be utilized in new deployments in preference to the deprecated identifier, unless there exist documented operational or regulatory requirements that prevent migration away from the deprecated identifier. 🍓
  • Prohibited: The identifier and the functionality that it references MUST NOT be used. (Identifiers may be designated as "Prohibited" due to security flaws, for instance.) 🚫

For completeness, these definitions bring the full set of terms for the "Recommended" columns in the IANA COSE registries [IANA.COSE] to "Yes" [RFC8152], "No" [RFC8152], "Filter Only" [RFC9054], "Prohibited", and "Deprecated". So the "Recommended" column definition gets updated to this:

  • Recommended: Does the IETF have a consensus recommendation to use the algorithm? The legal values are "Yes", "No", "Filter Only", "Prohibited", and "Deprecated". 🌸

The set of terms for the "JOSE Implementation Requirements" columns in the IANA JOSE registries [IANA.JOSE] stays exactly the same, no changes there 🎀

Note that "Deprecated" and "Prohibited" have been used with a whole bunch of different meanings across different specs, and sometimes they weren't even defined in those specs at all 🙈 For example, a version of "Deprecated" shows up in the title of [RFC8996], but the actual spec text says "MUST NOT be used" instead. Very confusing, very relatable.

The definitions above were picked because they match every existing registration in both JOSE and COSE, so none of them need to change 🎉 They also match how the terms were already being used in JOSE. The only real change is that you can now clearly tell "Deprecated" apart from "Prohibited" in future COSE registrations. Main character energy for the registries 👑

5. Key Representations 🔑

The key representations for the new fully-specified algorithms defined by this specification are the same as the ones for the polymorphic algorithms they replace, except for the alg value, if it's included. For example, the representation for a key used with the Ed25519 algorithm is the same as the one specified in [RFC8037], except that the alg value would be Ed25519 instead of EdDSA, if it's included. Lowkey simple, highkey iconic ✨

6. Notes on Algorithms Not Updated 🦋

Some existing polymorphic algorithms aren't updated by this specification. This section explains why they got left out.

6.1. RSA Signing Algorithms

There are different points of view on whether the RS256, RS384, and RS512 algorithms should be considered fully specified or not, because they can operate on keys of different sizes. For instance, they can use both 2048- and 4096-bit keys. The same goes for the PS* algorithms 🤔

This document doesn't describe or request registration of any fully-specified RSA algorithms. Some RSA signing implementations, like FIPS-compliant Hardware Security Modules (HSMs) [FIPS.140-3], limit RSA key parameters to specific values with acceptable security characteristics. This approach could be extended to define fully-specified RSA algorithms in the future 🧚

That said, if it ever becomes useful to have RSA algorithm identifiers that are specific to particular key characteristics, a future specification could always register them. Future bestie, you've got this 💜

6.2. ECDH Key Agreement Algorithms

This specification doesn't update the ECDH algorithms, but it does describe how they could potentially be updated in the future, if needed. The registered JOSE and COSE ECDH algorithms are polymorphic because they don't specify the curve to be used for the ephemeral key 🌈

Fully-specified versions of these algorithms would specify all the choices needed, including the KDF and the curve. For instance, an algorithm performing ECDH-ES using the Concat KDF and the P-256 curve would be fully specified and could be defined and registered. This specification doesn't define and register replacement algorithms like that, but other specifications could do so in the future, if desired ✨

6.3. HSS/LMS Hash-Based Digital Signature Algorithm

The HSS-LMS algorithm registered by COSE is polymorphic, because the algorithm identifier doesn't specify the hash function to be used. Like ECDH, this specification doesn't register replacement algorithms, but future specifications could 🌸

7. Security Considerations 💀🔐

Okay, this section is the serious one, bestie, so pay attention 😭

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

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

An "attack signature" is a unique pattern or characteristic used to identify malicious activity, letting systems 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 try to dodge 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 harder, because every variant of the algorithm has to be accounted for. For example, ES384 in COSE might be used with three different keys, each with a different curve. Chaos, honestly 🙈

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. This is a MUST-level vibe check, no cap 🔥

In COSE, preventing cross-protocol attacks, like the ones 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 🫠

8. References 📚

8.1. Normative References

8.2. Informative References ✨

okay so this is the bit where the RFC says "here's the extra reading, bestie" 📚💖 these ones aren't required to implement the spec, but they're the receipts for everything it's referencing 💅

Acknowledgements 🫶

the authors gave a huge shoutout to 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. the whole squad really showed up 👑✨

Authors' Addresses 🦋

Michael B. Jones Self-Issued Consulting Email: michael_b_jones@hotmail.com URI: https://self-issued.info/

Orie Steele Tradeverifyd Email: orie@or13.io

📦 where this page comes from