Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
updates
Extracted elements (20)
ECDH key agreement algorithms are not updated because doing so would require specifying the curve, KDF, and other parameters; while the specification describes how this could be done (e.g., 'ECDH-ES using Concat KDF and P-256'), it does not register such replacements, leaving this to future specifications if needed.
Polymorphic algorithm identifiers (e.g., EdDSA, COSE ES256) require information beyond the algorithm identifier—such as the key's curve—to determine the cryptographic operations. This breaks protocol negotiation mechanisms (OAuth AS Metadata, OpenID Connect Discovery, WebAuthn/CTAP) that negotiate solely by algorithm identifier, causing real interoperability problems in practice.
RSA signing algorithms (RS256/RS384/RS512 and PS*) are not updated because there is disagreement about whether they are already fully specified—they operate on keys of varying sizes (e.g., 2048-bit vs 4096-bit). FIPS-compliant HSMs restrict RSA key parameters, suggesting a possible future approach, but no registration is made here.
The COSE HSS-LMS hash-based signature algorithm is polymorphic because the algorithm identifier does not specify the hash function. Like ECDH, this specification does not register replacement fully-specified algorithms, leaving this to future specifications.
WebAuthn works around COSE EdDSA polymorphism by redefining algorithm -8 as 'EdDSA where crv is 6 (Ed25519)', effectively eliminating Ed448 support. This ad-hoc fix illustrates the broader problem that prompted this specification to define fully-specified algorithm identifiers ('cipher suite' approach) as replacements for polymorphic ('à la carte') identifiers.
JOSE ES256 is already fully specified (specifies P-256 curve and SHA-256), while the corresponding COSE ES256 (-7) is polymorphic (only specifies SHA-256, not the curve) and is now deprecated by this specification. Implementers must distinguish between JOSE and COSE registrations for identically-named algorithms.
A cryptographic key MUST be used with only a single algorithm unless the use of the same key with different algorithms is proven secure. It is RECOMMENDED that the 'alg' parameter of JSON Web Keys and COSE Keys be present, unless there is another mechanism ensuring the key is used as intended.
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. In COSE_Encrypt the outer 'alg' is in the COSE_Encrypt headers and the inner 'alg' is in the COSE_recipient headers.
To perform fully-specified encryption in JOSE, the 'alg' value MUST specify all parameters for key establishment (or derive some from the accompanying 'enc' value), and the 'enc' value MUST specify all parameters for symmetric encryption. Deriving parameters from 'enc' (e.g., keydatalen for ECDH-ES) does not make the algorithm polymorphic.
Updated review instructions for designated experts of both the JOSE 'JSON Web Signature and Encryption Algorithms' registry and the COSE 'COSE Algorithms' registry require that only fully-specified algorithm identifiers may be registered. Polymorphic algorithm identifiers must not be registered.
ECDH key establishment algorithms in both JOSE and COSE (ECDH-ES and ECDH-SS) remain polymorphic because they do not specify the elliptic curve for the ephemeral or static key. This specification does not deprecate them since replacements are not provided; future specifications could register fully-specified ECDH variants.
Key representations for the new fully-specified algorithms are identical to those for the polymorphic algorithms they replace, except for the 'alg' parameter value. For example, a key for Ed25519 uses the same structure as specified in RFC 8037 for EdDSA keys, with 'alg' set to 'Ed25519' rather than 'EdDSA'.
Many JOSE and COSE encryption algorithms are already fully specified: all symmetric encryption algorithms (e.g., A128GCM), all key-wrapping algorithms (e.g., A128KW), AES-GCM key wrapping, 'dir'/'direct', COSE direct+HKDF algorithms, and JOSE PBES2 key encryption algorithms. These do not require replacements.
Seven fully-specified COSE ECDSA algorithm identifiers are defined: ESP256 (-9, P-256/SHA-256, Recommended), ESP384 (-51, P-384/SHA-384, Recommended), ESP512 (-52, P-521/SHA-512, Recommended), ESB256 (-265, BrainpoolP256r1/SHA-256), ESB320 (-266, BrainpoolP320r1/SHA-384), ESB384 (-267, BrainpoolP384r1/SHA-384), and ESB512 (-268, BrainpoolP512r1/SHA-512). These replace the polymorphic COSE ES256/ES384/ES512 registrations.
This specification formally defines 'Deprecated' (a preferred replacement exists; new deployments SHOULD use it unless operational/regulatory requirements prevent migration) and 'Prohibited' (the identifier and its functionality MUST NOT be used) for use in JOSE and COSE IANA registries. For COSE, the complete set of 'Recommended' column values is now: Yes, No, Filter Only, Prohibited, and Deprecated.
Two fully-specified EdDSA algorithm identifiers are defined for both JOSE and COSE: Ed25519 (COSE value -19, EdDSA using the Ed25519 parameter set from RFC 8032 §5.1) and Ed448 (COSE value -53, EdDSA using the Ed448 parameter set from RFC 8032 §5.2). Both are JOSE Optional and COSE Recommended. These replace the polymorphic EdDSA identifiers in JOSE and COSE.
IANA has registered Ed25519 and Ed448 as fully-specified algorithm identifiers in the 'JSON Web Signature and Encryption Algorithms' registry (IANA.JOSE) established by RFC 7518, and has updated the JOSE EdDSA registration to 'Deprecated' implementation requirement status.
IANA has registered nine fully-specified COSE algorithm identifiers (ESP256 -9, ESP384 -51, ESP512 -52, ESB256 -265, ESB320 -266, ESB384 -267, ESB512 -268, Ed25519 -19, Ed448 -53) in the 'COSE Algorithms' registry and has updated ES256 (-7), ES384 (-35), ES512 (-36), and EdDSA (-8) to 'Deprecated' status.
Digital signature and key establishment algorithm identifiers can contribute to an 'attack signature' used by rule-based detection systems. Some software may vary the algorithm identifier to evade such detection. Detection systems should note that polymorphic algorithms are harder to enumerate in rules, since each curve variant must be accounted for separately.
To prevent cross-protocol attacks in COSE (as described in RFC 9459), implementations should either allow only authenticated content encryption (AEAD) algorithms, or bind the potentially unauthenticated content encryption algorithm to the key protection algorithm so different content encryption algorithms produce different content encryption keys.