Self-Issued Consulting

michael_b_jones@hotmail.com https://self-issued.info/

Tradeverifyd

orie@or13.io

SEC jose Cryptographic Algorithm Identifiers JSON Object Signing and Encryption (JOSE) CBOR Object Signing and Encryption (COSE) Polymorphic Algorithms Algorithm Cipher Suites This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053.

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 .

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 () 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

• .  Introduction
  • .  Requirements Notation and Conventions
• .  Fully-Specified Digital Signature Algorithm Identifiers
  • .  Elliptic Curve Digital Signature Algorithm (ECDSA)
  • .  Edwards-curve Digital Signature Algorithm (EdDSA)
• .  Fully-Specified Encryption
  • .  Fully-Specified Encryption Algorithms
  • .  Polymorphic Encryption Algorithms
• .  IANA Considerations
  • .  JOSE Algorithm Registrations
    • .  Fully-Specified JOSE Algorithm Registrations
    • .  Deprecated Polymorphic JOSE Algorithm Registration
  • .  COSE Algorithm Registrations
    • .  Fully-Specified COSE Algorithm Registrations
    • .  Deprecated Polymorphic COSE Algorithm Registrations
  • .  Updated Review Instructions for Designated Experts
    • .  JSON Web Signature and Encryption Algorithms
    • .  COSE Algorithms
  • .  Defining "Deprecated" and "Prohibited"
• .  Key Representations
• .  Notes on Algorithms Not Updated
  • .  RSA Signing Algorithms
  • .  ECDH Key Agreement Algorithms
  • .  HSS/LMS Hash-Based Digital Signature Algorithm
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction The IANA algorithm registries for JSON Object Signing and Encryption (JOSE) algorithms and CBOR Object Signing and Encryption (COSE) algorithms 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 and 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 and COSE and ES256 in COSE.

This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata uses negotiation parameters like these (from an example in that specification): "token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"] OpenID Connect Discovery likewise negotiates supported algorithms using "alg" and "enc" values. W3C Web Authentication and the FIDO Client to Authenticator Protocol (CTAP) 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.

Requirements Notation and Conventions 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 when, and only when, they appear in all capitals, as shown here.

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.

Elliptic Curve Digital Signature Algorithm (ECDSA) defines a way to use the Elliptic Curve Digital Signature Algorithm (ECDSA) with COSE. The COSE algorithm registrations for ECDSA are polymorphic, since they do not specify the curve used. For instance, ES256 is defined as "ECDSA w/ SHA-256" in . (The corresponding JOSE registrations in are fully specified.) The following fully-specified COSE ECDSA algorithms are defined by this specification: ECDSA Algorithm Values

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

Edwards-curve Digital Signature Algorithm (EdDSA) defines a way to use EdDSA with JOSE, and defines a way to use it with COSE. Both register polymorphic EdDSA algorithm identifiers. The following fully-specified JOSE and COSE EdDSA algorithms are defined by this specification: EdDSA Algorithm Values

Name	COSE Value	Description	JOSE Implementation Requirements	COSE Recommended
Ed25519	-19	EdDSA using the Ed25519 parameter set in	Optional	Yes
Ed448	-53	EdDSA using the Ed448 parameter set in	Optional	Yes

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 and , and COSE encryption, as described in and . 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 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 . 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 , 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 .

Fully-Specified Encryption Algorithms Many of the registered JOSE and COSE algorithms used for encryption are already fully specified. This section discusses them. All the symmetric encryption algorithms registered by and 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, all registered key wrapping algorithms are fully specified, as are the algorithms performing 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" and COSE "direct" algorithms are fully specified. The COSE direct+HKDF algorithms are fully specified. The JOSE algorithms performing Key Encryption with PBES2 are fully specified.

Polymorphic Encryption Algorithms Some of the registered JOSE and COSE algorithms used for encryption are polymorphic. This section discusses them. The Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms 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 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. See more discussion of ECDH algorithms in .

IANA Considerations

JOSE Algorithm Registrations IANA has registered the values in this section in the "JSON Web Signature and Encryption Algorithms" registry established by and has listed this document as an additional reference for the registry.

Fully-Specified JOSE Algorithm Registrations

Algorithm Name:

Ed25519

Algorithm Description:

EdDSA using the Ed25519 parameter set in

Algorithm Usage Locations:

alg

JOSE Implementation Requirements:

Optional

Change Controller:

IETF

Reference:

of RFC 9864

Algorithm Analysis Document(s):

Algorithm Name:

Ed448

Algorithm Description:

EdDSA using the Ed448 parameter set in

Algorithm Usage Locations:

alg

JOSE Implementation Requirements:

Optional

Change Controller:

IETF

Reference:

of RFC 9864

Algorithm Analysis Document(s):

Deprecated Polymorphic JOSE Algorithm Registration IANA has updated the status to "Deprecated" for the following registration.

Algorithm Name:

EdDSA

Algorithm Description:

EdDSA signature algorithms

Algorithm Usage Locations:

alg

JOSE Implementation Requirements:

Deprecated

Change Controller:

IETF

Reference:

of RFC 9864

Algorithm Analysis Document(s):

COSE Algorithm Registrations IANA has registered the following values in the "COSE Algorithms" registry established by and and has added this document as an additional reference for the registry.

Fully-Specified COSE Algorithm Registrations

Name:

ESP256

Value:

-9

Description:

ECDSA using P-256 curve and SHA-256

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

Yes

Name:

ESP384

Value:

-51

Description:

ECDSA using P-384 curve and SHA-384

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

Yes

Name:

ESP512

Value:

-52

Description:

ECDSA using P-521 curve and SHA-512

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

Yes

Name:

ESB256

Value:

-265

Description:

ECDSA using BrainpoolP256r1 curve and SHA-256

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

No

Name:

ESB320

Value:

-266

Description:

ECDSA using BrainpoolP320r1 curve and SHA-384

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

No

Name:

ESB384

Value:

-267

Description:

ECDSA using BrainpoolP384r1 curve and SHA-384

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

No

Name:

ESB512

Value:

-268

Description:

ECDSA using BrainpoolP512r1 curve and SHA-512

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

No

Name:

Ed25519

Value:

-19

Description:

EdDSA using the Ed25519 parameter set in

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

Yes

Name:

Ed448

Value:

-53

Description:

EdDSA using the Ed448 parameter set in

Capabilities:

[kty]

Change Controller:

IETF

Reference:

of RFC 9864

Recommended:

Yes

Deprecated Polymorphic COSE Algorithm Registrations IANA has updated the status to "Deprecated" and has added this document as a reference for the following registrations.

Name:

ES256

Value:

-7

Description:

ECDSA w/ SHA-256

Capabilities:

[kty]

Change Controller:

IETF

Reference:

and RFC 9864

Recommended:

Deprecated

Name:

ES384

Value:

-35

Description:

ECDSA w/ SHA-384

Capabilities:

[kty]

Change Controller:

IETF

Reference:

and RFC 9864

Recommended:

Deprecated

Name:

ES512

Value:

-36

Description:

ECDSA w/ SHA-512

Capabilities:

[kty]

Change Controller:

IETF

Reference:

and RFC 9864

Recommended:

Deprecated

Name:

EdDSA

Value:

-8

Description:

EdDSA

Capabilities:

[kty]

Change Controller:

IETF

Reference:

and RFC 9864

Recommended:

Deprecated

Updated Review Instructions for Designated Experts

JSON Web Signature and Encryption Algorithms The review instructions for the designated experts for the "JSON Web Signature and Encryption Algorithms" registry in have been updated to include an additional review criterion:

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

COSE Algorithms The review instructions for the designated experts for the "COSE Algorithms" registry in have been updated to include an additional review criterion:

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

Defining "Deprecated" and "Prohibited" The terms "Deprecated" and "Prohibited" as used by JOSE and COSE registrations are currently undefined. Furthermore, while in JOSE specifies that both "Deprecated" and "Prohibited" can be used, in COSE specifies the use of "Deprecated" but not "Prohibited". (Note that has been obsoleted by .) This section defines these terms for use by both JOSE and COSE IANA registrations in a consistent manner, eliminating this potentially confusing inconsistency. For purposes of use in the "JOSE Implementation Requirements" columns in the IANA JOSE registries and in the "Recommended" columns in the IANA COSE registries , these terms are defined as follows:

Deprecated

There is a preferred mechanism to achieve functionality similar to that referenced by the identifier; 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 set of defined terms for use in the "Recommended" columns in the IANA COSE registries to "Yes" , "No" , "Filter Only" , "Prohibited", and "Deprecated". This updates the definitions of the "Recommended" columns in these registries to be:

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 defined terms for use in the "JOSE Implementation Requirements" columns in the IANA JOSE registries are unchanged. Note that the terms "Deprecated" and "Prohibited" have been used with a multiplicity of different meanings in various specifications, sometimes without actually being defined in those specifications. For instance, a variation of the term "Deprecated" is used in the title of , but the actual specification text uses the terminology "MUST NOT be used". The definitions above were chosen because they are consistent with all existing registrations in both JOSE and COSE; none will need to change. Furthermore, they are consistent with their existing usage in JOSE. The only net change is to enable a clear distinction between "Deprecated" and "Prohibited" in future COSE registrations.

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 , except that the "alg" value would be Ed25519 rather than EdDSA, if included.

Notes on Algorithms Not Updated Some existing polymorphic algorithms are not updated by this specification. This section discusses why they have not been updated.

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 is true of the PS* algorithms. This document does not describe or request registration of any fully-specified RSA algorithms. Some RSA signing implementations, such as FIPS-compliant Hardware Security Modules (HSMs) 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, should it be useful at some point to have RSA algorithm identifiers that are specific to particular key characteristics, a future specification could always register them.

ECDH Key Agreement Algorithms This specification does not update the ECDH algorithms, but it describes how to potentially do so in the future, if needed. The registered JOSE and COSE ECDH algorithms are polymorphic because they do not specify the curve to be used for the ephemeral key. Fully-specified versions of these algorithms would specify all 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. While this specification does not define and register such replacement algorithms, other specifications could do so in the future, if desired.

HSS/LMS Hash-Based Digital Signature Algorithm The HSS-LMS algorithm registered by COSE is polymorphic. It is polymorphic because the algorithm identifier does not specify the hash function to be used. Like ECDH, this specification does not register replacement algorithms, but future specifications could do so.

Security Considerations The security considerations for ECDSA in , for EdDSA in , and for ECDSA and EdDSA in apply. The security considerations for preventing cross-protocol attacks described in 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 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 , 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. Informative References Yubico

jbradley@yubico.com

independent

michael_b_jones@hotmail.com http://self-issued.info/

Microsoft

akshayku@microsoft.com

Nok Nok Labs

rolf@noknok.com

OneSpan

johan.verrept@onespan.com

Ping Identity

dwaite@pingidentity.com

FIDO Alliance Proposed Standard NIST IANA IANA NAT.Consulting Yubico Self-Issued Consulting Illumila Ericsson This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE. PayPal

jdhodges@google.com

Mozilla

jc@mozilla.com

Microsoft

mbj@microsoft.com http://self-issued.info/

Microsoft

akshayku@microsoft.com

Yubico

emil@yubico.com

W3C Recommendation

Acknowledgements The authors thank , , , , , , , , , , , , , , , , , , , , , , , , , and for their contributions to this specification.

Authors' Addresses Self-Issued Consulting

michael_b_jones@hotmail.com https://self-issued.info/

Tradeverifyd

orie@or13.io