rfc9864v2.txt		rfc9864.txt
	Internet Engineering Task Force (IETF) M.B. Jones		Internet Engineering Task Force (IETF) M.B. Jones
	Request for Comments: 9864 Self-Issued Consulting		Request for Comments: 9864 Self-Issued Consulting
	Updates: 7518, 8037, 9053 O. Steele		Updates: 7518, 8037, 9053 O. Steele
	Category: Standards Track Transmute		Category: Standards Track Tradeverifyd
	ISSN: 2070-1721 September 2025		ISSN: 2070-1721 October 2025
	Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE)		Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE)
	and CBOR Object Signing and Encryption (COSE)		and CBOR Object Signing and Encryption (COSE)
	Abstract		Abstract
	This specification refers to cryptographic algorithm identifiers that		This specification refers to cryptographic algorithm identifiers that
	fully specify the cryptographic operations to be performed, including		fully specify the cryptographic operations to be performed, including
	any curve, key derivation function (KDF), and hash functions, as		any curve, key derivation function (KDF), and hash functions, as
	being "fully specified". It refers to cryptographic algorithm		being "fully specified". It refers to cryptographic algorithm
	skipping to change at line 123 ¶		skipping to change at line 123 ¶
	This matters because many protocols negotiate supported operations		This matters because many protocols negotiate supported operations
	using only algorithm identifiers. For instance, OAuth Authorization		using only algorithm identifiers. For instance, OAuth Authorization
	Server Metadata [RFC8414] uses negotiation parameters like these		Server Metadata [RFC8414] uses negotiation parameters like these
	(from an example in that specification):		(from an example in that specification):
	"token_endpoint_auth_signing_alg_values_supported":		"token_endpoint_auth_signing_alg_values_supported":
	["RS256", "ES256"]		["RS256", "ES256"]
	OpenID Connect Discovery [OpenID.Discovery] likewise negotiates		OpenID Connect Discovery [OpenID.Discovery] likewise negotiates
	supported algorithms using alg and enc values. W3C Web		supported algorithms using "alg" and "enc" values. W3C Web
	Authentication [WebAuthn] and the FIDO Client to Authenticator		Authentication [WebAuthn] and the FIDO Client to Authenticator
	Protocol (CTAP) [FIDO2] negotiate using COSE alg numbers.		Protocol (CTAP) [FIDO2] negotiate using COSE "alg" numbers.
	This does not work for polymorphic algorithms. For instance, with		This does not work for polymorphic algorithms. For instance, with
	EdDSA, it is not known which of the curves Ed25519 and/or Ed448 are		EdDSA, it is not known which of the curves Ed25519 and/or Ed448 are
	supported. This causes real problems in practice.		supported. This causes real problems in practice.
	WebAuthn contains this de facto algorithm definition to work around		WebAuthn contains this de facto algorithm definition to work around
	this problem:		this problem:
	-8 (EdDSA), where crv is 6 (Ed25519)		-8 (EdDSA), where crv is 6 (Ed25519)
	skipping to change at line 216 ¶		skipping to change at line 216 ¶
	2.2. Edwards-curve Digital Signature Algorithm (EdDSA)		2.2. Edwards-curve Digital Signature Algorithm (EdDSA)
	[RFC8037] defines a way to use EdDSA with JOSE, and [RFC9053] defines		[RFC8037] defines a way to use EdDSA with JOSE, and [RFC9053] defines
	a way to use it with COSE. Both register polymorphic EdDSA algorithm		a way to use it with COSE. Both register polymorphic EdDSA algorithm
	identifiers.		identifiers.
	The following fully-specified JOSE and COSE EdDSA algorithms are		The following fully-specified JOSE and COSE EdDSA algorithms are
	defined by this specification:		defined by this specification:
	+=========+=======+=============+=====================+=============+		+=========+=======+================+================+=============+
	| Name | COSE | Description | JOSE | COSE |		| Name | COSE | Description | JOSE | COSE |
	| | Value | | Implementation | Recommended |		| | Value | | Implementation | Recommended |
	| | | | Requirements | |		| | | | Requirements | |
	+=========+=======+=============+=====================+=============+		+=========+=======+================+================+=============+
	| Ed25519 | -19 | EdDSA using | Optional | Yes |		| Ed25519 | -19 | EdDSA using | Optional | Yes |
	| | | Ed25519 | | |		| | | the Ed25519 | | |
	| | | curve | | |		| | | parameter set | | |
	+---------+-------+-------------+---------------------+-------------+		| | | in Section 5.1 | | |
	| Ed448 | -53 | EdDSA using | Optional | Yes |		| | | of [RFC8032] | | |
	| | | Ed448 curve | | |		+---------+-------+----------------+----------------+-------------+
	+---------+-------+-------------+---------------------+-------------+		| Ed448 | -53 | EdDSA using | Optional | Yes |
			| | | the Ed448 | | |
			| | | parameter set | | |
			| | | in Section 5.2 | | |
			| | | of [RFC8032] | | |
			+---------+-------+----------------+----------------+-------------+
	Table 2: EdDSA Algorithm Values		Table 2: EdDSA Algorithm Values
	3. Fully-Specified Encryption		3. Fully-Specified Encryption
	This section describes the construction of fully-specified encryption		This section describes the construction of fully-specified encryption
	algorithm identifiers in the context of the JOSE and COSE encryption		algorithm identifiers in the context of the JOSE and COSE encryption
	schemes JSON Web Encryption (JWE), as described in [RFC7516] and		schemes JSON Web Encryption (JWE), as described in [RFC7516] and
	[RFC7518], and COSE Encrypt, as described in [RFC9052] and [RFC9053].		[RFC7518], and COSE encryption, as described in [RFC9052] and
			[RFC9053].
	Using fully-specified encryption algorithms enables the sender and		Using fully-specified encryption algorithms enables the sender and
	receiver to agree on all mandatory security parameters. They also		receiver to agree on all mandatory security parameters. They also
	enable protocols to specify an allow list of algorithm combinations		enable protocols to specify an allow list of algorithm combinations
	that does not include polymorphic combinations, preventing problems		that does not include polymorphic combinations, preventing problems
	such as cross-curve key establishment, cross-protocol symmetric		such as cross-curve key establishment, cross-protocol symmetric
	encryption, or mismatched KDF size to symmetric key scenarios.		encryption, or mismatched KDF size to symmetric key scenarios.
	Both JOSE and COSE have operations that take multiple algorithms as		Both JOSE and COSE have operations that take multiple algorithms as
	parameters. Encrypted objects in JOSE [RFC7516] use two algorithm		parameters. Encrypted objects in JOSE [RFC7516] use two algorithm
	skipping to change at line 299 ¶		skipping to change at line 305 ¶
	Many of the registered JOSE and COSE algorithms used for encryption		Many of the registered JOSE and COSE algorithms used for encryption
	are already fully specified. This section discusses them.		are already fully specified. This section discusses them.
	All the symmetric encryption algorithms registered by [RFC7518] and		All the symmetric encryption algorithms registered by [RFC7518] and
	[RFC9053] are fully specified. An example of a fully-specified		[RFC9053] are fully specified. An example of a fully-specified
	symmetric encryption algorithm is "A128GCM" (AES GCM using 128-bit		symmetric encryption algorithm is "A128GCM" (AES GCM using 128-bit
	key).		key).
	In both JOSE and COSE, all registered key wrapping algorithms are		In both JOSE and COSE, all registered key wrapping algorithms are
	fully specified, as are the key wrapping with AES GCM algorithms. An		fully specified, as are the algorithms performing key wrapping using
	example of a fully-specified key wrapping algorithm is "A128KW" (AES		AES GCM. An example of a fully-specified key wrapping algorithm is
	Key Wrap using 128-bit key).		"A128KW" (AES Key Wrap using 128-bit key).
	The JOSE "dir" and COSE "direct" algorithms are fully specified. The		The JOSE "dir" and COSE "direct" algorithms are fully specified. The
	COSE direct+HKDF algorithms are fully specified.		COSE direct+HKDF algorithms are fully specified.
	The JOSE Key Encryption with PBES2 algorithms are fully specified.		The JOSE algorithms performing Key Encryption with PBES2 are fully
			specified.
	3.2. Polymorphic Encryption Algorithms		3.2. Polymorphic Encryption Algorithms
	Some of the registered JOSE and COSE algorithms used for encryption		Some of the registered JOSE and COSE algorithms used for encryption
	are polymorphic. This section discusses them.		are polymorphic. This section discusses them.
	The Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms		The Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms
	in both JOSE and COSE are polymorphic because they do not specify the		in both JOSE and COSE are polymorphic because they do not specify the
	elliptic curve to be used for the key. This is true of the ephemeral		elliptic curve to be used for the key. This is true of the ephemeral
	key for the Ephemeral-Static (ES) algorithms registered for JOSE and		key for the Ephemeral-Static (ES) algorithms registered for JOSE and
	skipping to change at line 333 ¶		skipping to change at line 340 ¶
	4.1. JOSE Algorithm Registrations		4.1. JOSE Algorithm Registrations
	IANA has registered the values in this section in the "JSON Web		IANA has registered the values in this section in the "JSON Web
	Signature and Encryption Algorithms" registry [IANA.JOSE] established		Signature and Encryption Algorithms" registry [IANA.JOSE] established
	by [RFC7518] and has listed this document as an additional reference		by [RFC7518] and has listed this document as an additional reference
	for the registry.		for the registry.
	4.1.1. Fully-Specified JOSE Algorithm Registrations		4.1.1. Fully-Specified JOSE Algorithm Registrations
	Algorithm Name: Ed25519		Algorithm Name: Ed25519
	Algorithm Description: EdDSA using Ed25519 curve		Algorithm Description: EdDSA using the Ed25519 parameter set in
			Section 5.1 of [RFC8032]
	Algorithm Usage Locations: alg		Algorithm Usage Locations: alg
	JOSE Implementation Requirements: Optional		JOSE Implementation Requirements: Optional
	Change Controller: IETF		Change Controller: IETF
	Reference: Section 2.2 of RFC 9864		Reference: Section 2.2 of RFC 9864
	Algorithm Analysis Document(s): [RFC8032]		Algorithm Analysis Document(s): [RFC8032]
	Algorithm Name: Ed448		Algorithm Name: Ed448
	Algorithm Description: EdDSA using Ed448 curve		Algorithm Description: EdDSA using the Ed448 parameter set in
			Section 5.2 of [RFC8032]
	Algorithm Usage Locations: alg		Algorithm Usage Locations: alg
	JOSE Implementation Requirements: Optional		JOSE Implementation Requirements: Optional
	Change Controller: IETF		Change Controller: IETF
	Reference: Section 2.2 of RFC 9864		Reference: Section 2.2 of RFC 9864
	Algorithm Analysis Document(s): [RFC8032]		Algorithm Analysis Document(s): [RFC8032]
	4.1.2. Deprecated Polymorphic JOSE Algorithm Registration		4.1.2. Deprecated Polymorphic JOSE Algorithm Registration
	IANA has updated the status to "Deprecated" for the following		IANA has updated the status to "Deprecated" for the following
	registration.		registration.
	skipping to change at line 427 ¶		skipping to change at line 436 ¶
	Name: ESB512		Name: ESB512
	Value: -268		Value: -268
	Description: ECDSA using BrainpoolP512r1 curve and SHA-512		Description: ECDSA using BrainpoolP512r1 curve and SHA-512
	Capabilities: [kty]		Capabilities: [kty]
	Change Controller: IETF		Change Controller: IETF
	Reference: Section 2.1 of RFC 9864		Reference: Section 2.1 of RFC 9864
	Recommended: No		Recommended: No
	Name: Ed25519		Name: Ed25519
	Value: -19		Value: -19
	Description: EdDSA using Ed25519 curve		Description: EdDSA using the Ed25519 parameter set in Section 5.1 of
			[RFC8032]
	Capabilities: [kty]		Capabilities: [kty]
	Change Controller: IETF		Change Controller: IETF
	Reference: Section 2.2 of RFC 9864		Reference: Section 2.2 of RFC 9864
	Recommended: Yes		Recommended: Yes
	Name: Ed448		Name: Ed448
	Value: -53		Value: -53
	Description: EdDSA using Ed448 curve		Description: EdDSA using the Ed448 parameter set in Section 5.2 of
			[RFC8032]
	Capabilities: [kty]		Capabilities: [kty]
	Change Controller: IETF		Change Controller: IETF
	Reference: Section 2.2 of RFC 9864		Reference: Section 2.2 of RFC 9864
	Recommended: Yes		Recommended: Yes
	4.2.2. Deprecated Polymorphic COSE Algorithm Registrations		4.2.2. Deprecated Polymorphic COSE Algorithm Registrations
	IANA has updated the status to "Deprecated" and has added this		IANA has updated the status to "Deprecated" and has added this
	document as a reference for the following registrations.		document as a reference for the following registrations.
	skipping to change at line 505 ¶		skipping to change at line 516 ¶
	* Only fully-specified algorithm identifiers may be registered.		* Only fully-specified algorithm identifiers may be registered.
	Polymorphic algorithm identifiers must not be registered.		Polymorphic algorithm identifiers must not be registered.
	4.4. Defining "Deprecated" and "Prohibited"		4.4. Defining "Deprecated" and "Prohibited"
	The terms "Deprecated" and "Prohibited" as used by JOSE and COSE		The terms "Deprecated" and "Prohibited" as used by JOSE and COSE
	registrations are currently undefined. Furthermore, while in		registrations are currently undefined. Furthermore, while in
	[RFC7518] JOSE specifies that both "Deprecated" and "Prohibited" can		[RFC7518] JOSE specifies that both "Deprecated" and "Prohibited" can
	be used, in [RFC8152] COSE specifies the use of "Deprecated" but not		be used, in [RFC8152] COSE specifies the use of "Deprecated" but not
	"Prohibited". This section defines these terms for use by both JOSE		"Prohibited". (Note that [RFC8152] has been obsoleted by [RFC9052].)
	and COSE IANA registrations in a consistent manner, eliminating this		This section defines these terms for use by both JOSE and COSE IANA
	potentially confusing inconsistency.		registrations in a consistent manner, eliminating this potentially
			confusing inconsistency.
	For purposes of use in the "JOSE Implementation Requirements" columns		For purposes of use in the "JOSE Implementation Requirements" columns
	in the IANA JOSE registries [IANA.JOSE] and in the "Recommended"		in the IANA JOSE registries [IANA.JOSE] and in the "Recommended"
	columns in the IANA COSE registries [IANA.COSE], these terms are		columns in the IANA COSE registries [IANA.COSE], these terms are
	defined as follows:		defined as follows:
	Deprecated		Deprecated
	There is a preferred mechanism to achieve functionality similar to		There is a preferred mechanism to achieve functionality similar to
	that referenced by the identifier; this replacement functionality		that referenced by the identifier; this replacement functionality
	SHOULD be utilized in new deployments in preference to the		SHOULD be utilized in new deployments in preference to the
	skipping to change at line 533 ¶		skipping to change at line 545 ¶
	The identifier and the functionality that it references MUST NOT		The identifier and the functionality that it references MUST NOT
	be used. (Identifiers may be designated as "Prohibited" due to		be used. (Identifiers may be designated as "Prohibited" due to
	security flaws, for instance.)		security flaws, for instance.)
	For completeness, these definitions bring the set of defined terms		For completeness, these definitions bring the set of defined terms
	for use in the "Recommended" columns in the IANA COSE registries		for use in the "Recommended" columns in the IANA COSE registries
	[IANA.COSE] to "Yes" [RFC8152], "No" [RFC8152], "Filter Only"		[IANA.COSE] to "Yes" [RFC8152], "No" [RFC8152], "Filter Only"
	[RFC9054], "Prohibited", and "Deprecated". This updates the		[RFC9054], "Prohibited", and "Deprecated". This updates the
	definitions of the "Recommended" columns in these registries to be:		definitions of the "Recommended" columns in these registries to be:
	Recommended: Does the IETF have a consensus recommendation to use		Recommended
	the algorithm? The legal values are "Yes", "No", "Filter Only",		Does the IETF have a consensus recommendation to use the
			algorithm? The legal values are "Yes", "No", "Filter Only",
	"Prohibited", and "Deprecated".		"Prohibited", and "Deprecated".
	The set of defined terms for use in the "JOSE Implementation		The set of defined terms for use in the "JOSE Implementation
	Requirements" columns in the IANA JOSE registries [IANA.JOSE] are		Requirements" columns in the IANA JOSE registries [IANA.JOSE] are
	unchanged.		unchanged.
	Note that the terms "Deprecated" and "Prohibited" have been used with		Note that the terms "Deprecated" and "Prohibited" have been used with
	a multiplicity of different meanings in various specifications,		a multiplicity of different meanings in various specifications,
	sometimes without actually being defined in those specifications.		sometimes without actually being defined in those specifications.
	For instance, the term "Deprecated" is used in the title of		For instance, a variation of the term "Deprecated" is used in the
	[RFC8996], but the actual specification text uses the terminology		title of [RFC8996], but the actual specification text uses the
	"MUST NOT be used".		terminology "MUST NOT be used".
	The definitions above were chosen because they are consistent with		The definitions above were chosen because they are consistent with
	all existing registrations in both JOSE and COSE; none will need to		all existing registrations in both JOSE and COSE; none will need to
	change. Furthermore, they are consistent with their existing usage		change. Furthermore, they are consistent with their existing usage
	in JOSE. The only net change is to enable a clear distinction		in JOSE. The only net change is to enable a clear distinction
	between "Deprecated" and "Prohibited" in future COSE registrations.		between "Deprecated" and "Prohibited" in future COSE registrations.
	5. Key Representations		5. Key Representations
	The key representations for the new fully-specified algorithms		The key representations for the new fully-specified algorithms
	defined by this specification are the same as those for the		defined by this specification are the same as those for the
	polymorphic algorithms that they replace, other than the alg value,		polymorphic algorithms that they replace, other than the "alg" value,
	if included. For instance, the representation for a key used with		if included. For instance, the representation for a key used with
	the Ed25519 algorithm is the same as that specified in [RFC8037],		the Ed25519 algorithm is the same as that specified in [RFC8037],
	except that the alg value would be Ed25519 rather than EdDSA, if		except that the "alg" value would be Ed25519 rather than EdDSA, if
	included.		included.
	6. Notes on Algorithms Not Updated		6. Notes on Algorithms Not Updated
	Some existing polymorphic algorithms are not updated by this		Some existing polymorphic algorithms are not updated by this
	specification. This section discusses why they have not been		specification. This section discusses why they have not been
	updated.		updated.
	6.1. RSA Signing Algorithms		6.1. RSA Signing Algorithms
	skipping to change at line 687 ¶		skipping to change at line 700 ¶
	Structures and Process", STD 96, RFC 9052,		Structures and Process", STD 96, RFC 9052,
	DOI 10.17487/RFC9052, August 2022,		DOI 10.17487/RFC9052, August 2022,
	<https://www.rfc-editor.org/info/rfc9052>.		<https://www.rfc-editor.org/info/rfc9052>.
	[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):		[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,		Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
	August 2022, <https://www.rfc-editor.org/info/rfc9053>.		August 2022, <https://www.rfc-editor.org/info/rfc9053>.
	8.2. Informative References		8.2. Informative References
	[FIDO2] Bradley, J., Jones, M., Kumar, A., Lindemann, R., Johan,		[FIDO2] Bradley, J., Jones, M.B., Kumar, A., Lindemann, R.,
	J., and D. David, "Client to Authenticator Protocol		Verrept, J., and D. Waite, "Client to Authenticator
	(CTAP)", FIDO Alliance Proposed Standard, 28 February		Protocol (CTAP)", FIDO Alliance Proposed Standard, 14 July
	2025, <https://fidoalliance.org/specs/fido-v2.2-ps-		2025, <https://fidoalliance.org/specs/fido-v2.2-ps-
	20250228/fido-client-to-authenticator-protocol-v2.2-ps-		20250714/fido-client-to-authenticator-protocol-v2.2-ps-
	20250228.html>.		20250714.html>.
	[FIPS.140-3]		[FIPS.140-3]
	NIST, "Security Requirements for Cryptographic Modules",		NIST, "Security Requirements for Cryptographic Modules",
	NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,		NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/		<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.140-3.pdf>.		NIST.FIPS.140-3.pdf>.
	[IANA.COSE]		[IANA.COSE]
	IANA, "CBOR Object Signing and Encryption (COSE)",		IANA, "CBOR Object Signing and Encryption (COSE)",
	<https://www.iana.org/assignments/cose/>.		<https://www.iana.org/assignments/cose/>.
	[IANA.JOSE]		[IANA.JOSE]
	IANA, "JSON Object Signing and Encryption (JOSE)",		IANA, "JSON Object Signing and Encryption (JOSE)",
	<https://www.iana.org/assignments/jose/>.		<https://www.iana.org/assignments/jose/>.
	[OpenID.Discovery]		[OpenID.Discovery]
	Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,		Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
	"OpenID Connect Discovery 1.0 incorporating errata set 2",		Connect Discovery 1.0 incorporating errata set 2", 15
	15 December 2023, <https://openid.net/specs/openid-		December 2023, <https://openid.net/specs/openid-connect-
	connect-discovery-1_0.html>.		discovery-1_0.html>.
	[Reuse25519]		[Reuse25519]
	Thormarker, E., "On using the same key pair for Ed25519		Thormarker, E., "On using the same key pair for Ed25519
	and an X25519 based KEM", 23 April 2021,		and an X25519 based KEM", 23 April 2021,
	<https://eprint.iacr.org/2021/509.pdf>.		<https://eprint.iacr.org/2021/509.pdf>.
	[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,		[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
	DOI 10.17487/RFC7518, May 2015,		DOI 10.17487/RFC7518, May 2015,
	<https://www.rfc-editor.org/info/rfc7518>.		<https://www.rfc-editor.org/info/rfc7518>.
	skipping to change at line 779 ¶		skipping to change at line 792 ¶
	Jiankang Yao for their contributions to this specification.		Jiankang Yao for their contributions to this specification.
	Authors' Addresses		Authors' Addresses
	Michael B. Jones		Michael B. Jones
	Self-Issued Consulting		Self-Issued Consulting
	Email: michael_b_jones@hotmail.com		Email: michael_b_jones@hotmail.com
	URI: https://self-issued.info/		URI: https://self-issued.info/
	Orie Steele		Orie Steele
	Transmute		Tradeverifyd
	Email: orie@transmute.industries		Email: orie@or13.io
End of changes. 20 change blocks.
	44 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.48.