Self-Issued Consulting

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

Transmute

orie@transmute.industries

Security JOSE Working Group Cryptographic Algorithm Identifiers JSON Object Signing and Encryption (JOSE) CBOR Object Signing and Encryption (COSE) Polymorphic Algorithms Algorithm Cipher Suites Internet-Draft This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, 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 JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers.

The IANA algorithm registries for JOSE and COSE contain two kinds of algorithm identifiers: Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc. Examples are RS256 and ES256K in both JOSE and COSE and ES256 in JOSE. 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 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 the specification):

OpenID Connect Discovery likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication and 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:

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.

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.

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

defines the current use of the Elliptic Curve Digital Signature Algorithm (ECDSA) by 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 Section 2.1 of . (The corresponding JOSE registrations in are full-specified.) The following fully-specified COSE ECDSA algorithms are defined: Name COSE Value Description COSE Recommended ESP256 TBD (requested assignment -9) ECDSA using P-256 curve and SHA-256 Yes ESP384 TBD (requested assignment -48) ECDSA using P-384 curve and SHA-384 Yes ESP512 TBD (requested assignment -49) ECDSA using P-521 curve and SHA-512 Yes ESB256 TBD (requested assignment -265) ECDSA using BrainpoolP256r1 curve and SHA-256 No ESB320 TBD (requested assignment -266) ECDSA using BrainpoolP320r1 curve and SHA-384 No ESB384 TBD (requested assignment -267) ECDSA using BrainpoolP384r1 curve and SHA-384 No ESB512 TBD (requested assignment -268) ECDSA using BrainpoolP512r1 curve and SHA-512 No

defines the current use of the Edwards-Curve Digital Signature Algorithm (EdDSA) by JOSE and defines its current use by COSE. Both register polymorphic EdDSA algorithm identifiers. The following fully-specified JOSE and COSE EdDSA algorithms are defined: Name COSE Value Description JOSE Implementation Requirements COSE Recommended Ed25519 TBD (requested assignment -50) EdDSA using Ed25519 curve Optional Yes Ed448 TBD (requested assignment -51) EdDSA using Ed448 curve Optional Yes

This section describes the construction of fully-specified encryption algorithm identifiers in the context of existing the JOSE and COSE encryption schemes JSON Web Encryption, (JWE) as described in and , and COSE Encrypt, 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 essential parameters for key establishment or derive some of them from the accompanying "enc" value and the "enc" value MUST specify all essential parameters for symmetric encryption. For example, JWE encryption 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. An example of this is that the keydatalen KDF parameter value for "ECDH-ES" is determined from the "enc" value, as described in Section 4.6.2 of . 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 essential parameters for key establishment and the inner "alg" value must specify all essential parameters for symmetric encryption. For example, COSE encryption using an outer "alg" value of A128KW and an inner "alg" value of A128GCM uses fully-specified algorithms. 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 .

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 key wrapping with AES GCM algorithms. 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 Key Encryption with PBES2 algorithms are fully specified.

Some of the registered JOSE and COSE algorithms used for encryption are polymorphic. This section discusses them. The 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 .

This section registers the following values in the IANA "JSON Web Signature and Encryption Algorithms" registry established by .

Algorithm Name: Ed25519 Algorithm Description: EdDSA using Ed25519 curve Algorithm Usage Locations: alg JOSE Implementation Requirements: Optional Change Controller: IETF Reference: of [[ this specification ]] Algorithm Analysis Document(s):   Algorithm Name: Ed448 Algorithm Description: EdDSA using Ed448 curve Algorithm Usage Locations: alg JOSE Implementation Requirements: Optional Change Controller: IETF Reference: of [[ this specification ]] Algorithm Analysis Document(s):

The following registration is updated to change its status to Deprecated. Algorithm Name: EdDSA Algorithm Description: EdDSA signature algorithms Algorithm Usage Locations: alg JOSE Implementation Requirements: Deprecated Change Controller: IETF Reference: of [[ this specification ]] Algorithm Analysis Document(s):

This section registers the following values in the IANA "COSE Algorithms" registry .

Name: ESP256 Value: TBD (requested assignment -9) Description: ECDSA using P-256 curve and SHA-256 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: Yes   Name: ESP384 Value: TBD (requested assignment -48) Description: ECDSA using P-384 curve and SHA-384 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: Yes   Name: ESP512 Value: TBD (requested assignment -49) Description: ECDSA using P-521 curve and SHA-512 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: Yes   Name: ESB256 Value: TBD (requested assignment -261) Description: ECDSA using BrainpoolP256r1 curve and SHA-256 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: No   Name: ESB320 Value: TBD (requested assignment -262) Description: ECDSA using BrainpoolP320r1 curve and SHA-384 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: No   Name: ESB384 Value: TBD (requested assignment -263) Description: ECDSA using BrainpoolP384r1 curve and SHA-384 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: No   Name: ESB512 Value: TBD (requested assignment -264) Description: ECDSA using BrainpoolP512r1 curve and SHA-512 Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: No   Name: Ed25519 Value: TBD (requested assignment -50) Description: EdDSA using Ed25519 curve Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: Yes   Name: Ed448 Value: TBD (requested assignment -51) Description: EdDSA using Ed448 curve Capabilities: [kty] Change Controller: IETF Reference: of [[ this specification ]] Recommended: Yes

The following registrations are updated to change their status to Deprecated. Name: ES256 Value: -7 Description: ECDSA w/ SHA-256 Capabilities: [kty] Change Controller: IETF Reference: RFC 9053 Recommended: Deprecated   Name: ES384 Value: -35 Description: ECDSA w/ SHA-384 Capabilities: [kty] Change Controller: IETF Reference: RFC 9053 Recommended: Deprecated   Name: ES512 Value: -36 Description: ECDSA w/ SHA-512 Capabilities: [kty] Change Controller: IETF Reference: RFC 9053 Recommended: Deprecated   Name: EdDSA Value: -8 Description: EdDSA Capabilities: [kty] Change Controller: IETF Reference: RFC 9053 Recommended: Deprecated

IANA is directed to preserve the current reference to RFC 7518, and to add a reference to this section of this specification. The review instructions for the designated experts for the IANA "JSON Web Signature and Encryption Algorithms" registry in Section 7.1 of have been updated to include an additional review criterion: Only fully-specified algorithm identifiers may be registered. Polymorphic algorithm identifiers must not be registered.

IANA is directed to preserve the current references to RFC 9053 and RFC 9054, and to add a reference to this section of this specification. The review instructions for the designated experts for the IANA "COSE Algorithms" registry in Section 10.4 of have been updated to include an additional review criterion: Only fully-specified algorithm identifiers may be registered. Polymorphic algorithm identifiers must not be registered.

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 did not carry the definitions of the "Recommended" registry columns forward, so remains definitive in this regard.) 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: There is a preferred mechanism to achieve similar functionality 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. The identifier and the functionality that it references MUST NOT be used. (Identifiers MAY be designated as "Prohibited" due to security flaws, for instance.) 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, 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.

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.

The working group has discussed some existing polymorphic algorithms that are not updated by this specification. This section discusses why they have not been updated.

The working group has discussed 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.

The working group decided not to update the Elliptic Curve Diffie-Hellman (ECDH) algorithms at this time, but to describe 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 there was not an appetite in the working group to define and register such replacement algorithms at this time, other specifications could do so in the future, if desired.

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, the working group did not propose to register replacement algorithms, but future specifications could do so.

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 sofware 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 3 different keys, each with a different curve. A cryptographic key SHOULD 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 the key is used as intended. In COSE, preventing cross-protocol attacks, such as those described in , can be accomplished in two ways: Allow only authenticated content encryption algorithms. Bind the the potentially unauthenticated content encryption algorithm to be used into 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.

IANA IANA NAT.Consulting Yubico Self-Issued Consulting Illumila PayPal

jdhodges@google.com

Mozilla

jc@mozilla.com

Microsoft

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

Microsoft

akshayku@microsoft.com

Yubico

emil@yubico.com

Yubico

jbradley@yubico.com

PayPal

jdhodges@google.com

Microsoft

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

Microsoft

akshayku@microsoft.com

Nok Nok Labs

rolf@noknok.com

OneSpan

johan.verrept@onespan.com

National Institute of Standards and Technology (NIST) Ericsson

[[ to be removed by the RFC Editor before publication as an RFC ]] -09 Addressed comments from secdir review. -08 Updated requested Brainpool algorithm numbers to match those chosen by Sean Turner. Incorporated wording suggestions by Vijay Gurbani. -07 Addressed Deb Cooley's Area Director feedback. Specifically: Significantly simplified the encryption description. Removed the appendix on polymorphic ECDH algorithms. Stated that HSS-LMS is not fully specified, as suggested by John Preuß Mattsson. -06 Corrected inconsistencies identified during the 2nd WGLC. Added terminology remark about the "cipher suite" and "à la carte" approaches. -05 Applied IANA early review comments. -04 Removed ECDH registrations and proposed fully-specified ECDH algorithm identifiers, per feedback at IETF 120. Tightened descriptive text for fully-specified encryption algorithms. Applied John Mattsson's suggestion for the RSA section title. -03 Acknowledged contributions made during Working Group Last Call. Addressed security considerations feedback from WGLC. Made COSE Recommended status for Ed25519 and Ed448 "yes". Registered COSE algorithms for using Brainpool curves with ECDSA. Removed text on KEMs, since currently registered algorithms don't use them. Enabled use of fully-specified ECDH algorithms. Defined the terms "Deprecated" and "Prohibited" for both JOSE and COSE registrations. -02 Expanded references for KEMs. Added example of a fully-specified KEM. -01 Included additional instructions for IANA. Added text on KEMs and Encapsulated keys. Added the section Fully-Specified Computations Using Multiple Algorithms. -00 Created initial working group version based on draft-jones-jose-fully-specified-algorithms-02.

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