Fully-Specified Algorithms for JOSE and COSESelf-Issued Consultingmichael_b_jones@hotmail.comhttps://self-issued.info/Transmuteorie@transmute.industries
Security
JOSE Working GroupCryptographic Algorithm IdentifiersJSON Object Signing and Encryption (JOSE)CBOR Object Signing and Encryption (COSE)Polymorphic AlgorithmsAlgorithm Cipher SuitesInternet-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, you do not know 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.
It furthermore 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 all 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:
NameCOSE ValueDescriptionCOSE RecommendedESP256TBD (requested assignment -9)ECDSA using P-256 curve and SHA-256YesESP384TBD (requested assignment -48)ECDSA using P-384 curve and SHA-384YesESP512TBD (requested assignment -49)ECDSA using P-521 curve and SHA-512YesESB256TBD (requested assignment -261)ECDSA using BrainpoolP256r1 curve and SHA-256NoESB320TBD (requested assignment -262)ECDSA using BrainpoolP320r1 curve and SHA-384NoESB384TBD (requested assignment -263)ECDSA using BrainpoolP384r1 curve and SHA-384NoESB512TBD (requested assignment -264)ECDSA using BrainpoolP512r1 curve and SHA-512No 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:
NameCOSE ValueDescriptionJOSE Implementation RequirementsCOSE RecommendedEd25519TBD (requested assignment -50)EdDSA using Ed25519 curveOptionalYesEd448TBD (requested assignment -51)EdDSA using Ed448 curveOptionalYes
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
COSE Encrypt as described in .
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.
The following sections describe how to fully specify encryption algorithms
when multiple algorithms are used in the computation.
JOSE and COSE support several modes of encryption.
Although the terminology sometimes differs between JOSE and COSE,
both support these encryption modes:
Direct Encryption - A symmetric cryptographic operation.
Key Establishment with Direct Encryption - An asymmetric cryptographic operation to derive a shared secret, key derivation and then a symmetric cryptographic operation.
Two-Layer Encryption - A content encryption key is protected (multiple possible ways), then content encryption or decryption is performed using the protected content encryption key.
Mode complexity creates the following risks:
The combination of chosen algorithms might not be implemented by the receiver.
The combination of chosen algorithms might not be aligned in terms of strength.
Underspecified or implicit parameters could lead to exploitable faults in implementations, for example,
cross-curve Elliptic Curve Diffie-Hellman (ECDH) between P-256 and P-384 or X25519.
Alternative algorithms at a component layer, such as symmetric key encryption, might provide different security properties, for example, "A128GCM" vs. "A128CBC-HS256".
While this specification provides a definition of what fully-specified encryption algorithm identifiers are for both JOSE and COSE, including examples,
it does not deprecate any polymorphic encryption algorithms,
since replacements for them are not provided by this specification.
The following sections describe what fully specified means for each mode.
Symmetric encryption algorithms generally satisfy the following interface:
secret_key = key_generation(algorithm_identifier)
ciphertext = encrypt(plaintext, secret_key)
plaintext = decrypt(ciphertext, secret_key)
Depending on the algorithm, additional parameters such as Additional Authenticated Data (AAD) or Initialization Vector (IV) might be required.
In the special case where the plaintext is a content encryption key, to be used with a subsequent symmetric encryption algorithm,
such a symmetric encryption algorithm is referred to as a key wrapping algorithm and the secret_key is referred to as a key wrapping key.
An example of a fully-specified symmetric encryption algorithm is "A128GCM" (AES GCM using 128-bit key).
An example of a fully-specified key wrapping algorithm is "A128KW" (AES Key Wrap using 128-bit key).
A symmetric encryption algorithm is fully specified when it satisfies the interface above, and depends only on the parameters to the encrypt and decrypt operations.
Direct Encryption and Key Wrapping algorithms encode the primary symmetric key parameter (key length) in the algorithm identifier.
In JOSE and COSE, all currently registered Direct Encryption and Key Wrapping algorithms are fully specified.
Example of a decoded JWE Protected Header, for Direct Encryption:
{
"alg": "dir",
"enc": "A128GCM",
...
}
Example of a decoded JWE Protected Header, for Key Wrapping:
{
"alg": "A128KW",
"enc": "A128GCM",
...
}
Key establishment with direct encryption algorithms generally satisfy the following interface:
private_key, public_key = key_generation(algorithm_identifier)
ciphertext = encrypt(plaintext, public_key)
plaintext = decrypt(ciphertext, private_key)
Depending on the symmetric algorithm, additional parameters such as Additional Authenticated Data (AAD) or Initialization Vector (IV) might be required.
Although JOSE and COSE encode this type of encryption differently, both rely on a symmetric key derived from an asymmetric key.
An algorithm called a key derivation function (KDF) is applied between key establishment and symmetric encryption.
Key establishment algorithms often rely on an asymmetric cryptographic operation whereby a public and a private key are used to produce a shared secret, which can be combined with a KDF to produce a symmetric key.
The process of producing a shared secret is key type specific, and is different for elliptic curves, RSA, and lattice-based algorithms.
Elliptic Curve Diffie-Hellman (ECDH) is used to produce a shared secret with elliptic curve-based keys as follows:
private_key1, public_key1 = key_generation(algorithm_identifier)
private_key2, public_key2 = key_generation(algorithm_identifier)
shared_secret = derive_shared_secret(public_key1, private_key2)
shared_secret = derive_shared_secret(public_key2, private_key1)
An algorithm called a Key Encapsulation Mechanism (KEM) can be used to provide a common interface for deriving shared secrets, regardless of key type.
For examples of the use of KEMs,
see
and .
Key encapsulation algorithms generally satisfy the following interface:
private_key, public_key = key_generation(algorithm_identifier)
ciphertext, shared_secret = encapsulate(public_key)
shared_secret = deencapsulate(ciphertext, private_key)
When using Key Establishment with Direct Encryption, the ciphertext is not only the output of symmetric encryption, but also includes all parameters necessary for the recipient to decrypt the ciphertext.
Encrypted content encryption keys are not produced by fully-specified Key Establishment with Direct Encryption algorithms.
In JOSE, the KDF algorithm is "Concat KDF" and is an implicit parameter of the key establishment algorithm.
In JOSE and COSE, key establishment algorithms have historically been generic to a key type including all its mandatory parameters.
For example, "ECDH-ES" establishes a shared secret, and then through the use of a KDF, a content encryption key, for keys based on elliptic curves.
However, the mandatory parameters of the public key and private key need be the same in the context of the key type.
For example, when using ECDH-ES with secp256r1 (P-256) to establish a shared secret,
the ECDH algorithm is a function of an ephemeral and a static key,
which need to be of the same key type, and having the same parameters, in this case, the curve parameter.
To successfully encrypt to a recipient, a sender needs to possess the recipient's key (which contains the curve parameter) and know the recipient's supported algorithms.
In JOSE and COSE, key representations can support communicating the algorithm that a recipient supports for a given key.
It is considered a best practice to only use a key with one algorithm.
Example of a decoded JWE Protected Header, for Key Establishment with Direct Encryption:
{
"alg":"ECDH-ES",
"enc":"A128GCM",
...
}
Despite containing both the key establishment algorithm (with an implicit KDF) and the symmetric encryption algorithm, the example above is not fully specified.
To make a Key Establishment with Direct Encryption algorithm fully specified, all essential parameters need to be encoded in the algorithm identifiers.
In the example above, the missing explicit parameters are curve name and KDF name.
If the KDF requires additional parameters, they also need to be present.
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 convey fully-specified Key Establishment with Direct 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,
an "alg" value specifiying ECDH-ES using P-256 and Concat-KDF and
an "enc" value of "A128GCM".
To convey fully-specified Key Establishment with Direct 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,
an outer "alg" value specifying ECDH-ES using P-256 and HKDF SHA-256 with 128-bit output and
an inner "alg" value specifying A128GCM.
This section describes Two-Layer Encryption in both JOSE and COSE.
Each defines multiple ways that a content encryption key can be produced and protected, then later used to decrypt or encrypt content.
This specification uses the term "Two-Layer Encryption" to refer to what JOSE describes as "Key Encryption" and "Key Agreement with Key Wrapping", and what COSE describes as "Key Transport" and "Key Agreement with Key Wrap".
A distinguishing characteristic of Two-Layer Encryption schemes is that multiple recipients can perform decryptions, using a wide range of algorithms, and that encrypted content encryption keys are always present.
In RSA-OAEP, the content encryption key is encrypted using an asymmetric cryptographic operation.
When Key Wrapping without any key establishment is used,
the content encryption key is encrypted using a symmetric cryptographic operation (key wrap).
How the content encryption key is generated is out of scope for this discussion.
Key wrapping algorithms generally satisfy the following interface:
key_encryption_key = \
key_generation(algorithm_identifier)
encrypted_content_encryption_key = \
encrypt(content_encryption_key, key_encryption_key)
content_encryption_key = \
decrypt(encrypted_content_encryption_key, key_encryption_key)
When Key Establishment with Key Wrapping is used, the content encryption key is protected with Key Wrapping, where the Key Encryption Key is derived from an asymmetric cryptographic operation and a key derivation function.
Key Establishment with Key Wrapping algorithms generally satisfy the following interface:
private_key, public_key = key_generation(algorithm_identifier)
# ignoring ephemeral/static vs. static/static, etc.
key_encryption_key = \
key_establishment(public_key, private_key)
encrypted_content_encryption_key = \
encrypt(content_encryption_key, key_encryption_key)
content_encryption_key = \
decrypt(encrypted_content_encryption_key, key_encryption_key)
The interface above is consistent with Key Establishment with Direct Encryption.
The process of deriving a shared secret and content encryption key is specific to the asymmetric key type used.
The difference is that instead of using the derived content encryption key directly, two-layer encryption always uses a key encryption key, and protects the content encryption key.
Regardless of how a Two-Layer Encryption scheme protects the content encryption key, content encryption algorithms generally satisfy the following interface:
content_encryption_key = \
unwrap or establish and unwrap or key transport...
ciphertext = encrypt(plaintext, content_encryption_key)
plaintext = decrypt(ciphertext, content_encryption_key)
Depending on the content encryption algorithm, additional parameters such as Additional Authenticated Data (AAD) and/or an Initialization Vector (IV) might be required.
Although JOSE and COSE encode Two-Layer Encryptions differently, both rely on a protected content encryption key.
The content encryption key is protected using Key Wrapping directly, or through Key Establishment and then Key Wrapping, or Key Transport, or Key Encryption.
When using Two-Layer Encryption, the output of symmetric encryption
includes the ciphertext and is accompanied by
all parameters necessary for the recipient to decrypt the ciphertext,
including parameters for use with the key establishment algorithm, such as ephemeral or encapsulated keys, any required key derivation functions and their parameters and the key wrapping algorithm.
Encrypted content encryption keys are always present when Two-Layer Encryption is used.
Parameters accompanying the ciphertext can include
an Initialization Vector (IV),
an Authentication Tag,
and Additional Authenticated Data (AAD).
Two-Layer Encryption is often used for encrypting the same plaintext to multiple recipients, in contrast with other modes that can only be used to encrypt to a single recipient.
Example of a decoded JWE Protected Header for Key Encryption with RSA OAEP
and Content Encryption using AES_128_CBC_HMAC_SHA_256:
{
"alg": "RSA-OAEP-256",
"enc": "A128CBC-HS256",
...
}
Example of a decoded JWE Protected Header for Key Agreement using ECDH-ES with key wrapping and Content Encryption using AES GCM:
{
"alg": "ECDH-ES+A128KW",
"enc": "A128GCM",
...
}
However, despite containing both the key establishment algorithm
and a content encryption algorithm, the second example above is not fully specified.
In this example, the missing parameter is
the curve name for the ephemeral key used for key agreement.
To convey fully-specified Two-Layer Encryption in JOSE,
the "alg" value MUST specify all essential parameters for key protection
or derive them from the accompanying "enc" value
and the "enc" value MUST be fully specified,
specifying all essential parameters for symmetric encryption.
For example,
ECDH-ES using Concat KDF and P-256 and "A128KW" key wrapping
used with AES-GCM.
To convey fully-specified Two-Layer Encryption in COSE,
the outer "alg" value MUST specify all essential parameters for key protection
and the inner "alg" value MUST be fully specified,
specifying all essential parameters for symmetric encryption.
For example,
ECDH-ES using P-256 w/ HKDF and AES Key Wrap w/ 128-bit key
used with AES-GCM.
In COSE, preventing cross-mode attacks, such as those described in , can be accomplished in two ways:
(1) Allow only authenticated content encryption algorithms.
(2) 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.
Fully-specified Two-Layer Encryption algorithms enable the sender and receiver to agree on all mandatory security parameters.
They also enable a protocol to specify an allow list of algorithm combinations that does not include polymorphic combinations,
such as cross-curve key establishment,
cross-mode symmetric encryption,
or mismatched KDF size to symmetric key scenarios.
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 requirments 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 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.
As discussed in ,
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 security considerations for ECDSA in ,
for EdDSA in , and
for ECDSA and EdDSA in apply.
The security considerations for preventing cross-mode attacks
described in apply.
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.
JSON Object Signing and Encryption (JOSE)IANACBOR Object Signing and Encryption (COSE)IANAOpenID Connect Discovery 1.0NAT.ConsultingYubicoSelf-Issued ConsultingIllumilaWeb Authentication: An API for accessing Public Key Credentials - Level 2PayPaljdhodges@google.comMozillajc@mozilla.comMicrosoftmbj@microsoft.comhttp://self-issued.info/Microsoftakshayku@microsoft.comYubicoemil@yubico.comClient to Authenticator Protocol (CTAP)Yubicojbradley@yubico.comPayPaljdhodges@google.comMicrosoftmbj@microsoft.comhttp://self-issued.info/Microsoftakshayku@microsoft.comNok Nok Labsrolf@noknok.comOneSpanjohan.verrept@onespan.comSecurity Requirements for Cryptographic ModulesNational Institute of Standards and Technology (NIST)On using the same key pair for Ed25519 and an X25519 based KEMEricsson
The working group assembled the following inventory of registered polymorphic
Elliptic Curve Diffie-Hellman (ECDH) JOSE and COSE algorithms
with the goal of understanding what
registering fully-specified ECDH algorithms to replace them would entail.
While there was not an appetite in the working group
to register these replacement algorithms at this time,
this inventory documents how to do so,
should others wish to register some or all of the replacements in the future.
These registered JOSE algorithms are polymorphic,
because they do not include the curve name in the algorithm to be used with the ephemeral key:
NameDescriptionECDH-ESECDH-ES using Concat KDFECDH-ES+A128KWECDH-ES using Concat KDF and "A128KW" wrappingECDH-ES+A192KWECDH-ES using Concat KDF and "A192KW" wrappingECDH-ES+A256KWECDH-ES using Concat KDF and "A256KW" wrapping
Descriptions of fully-specified JOSE versions of these algorithms
using combinations discussed by the working group
that could be registered by future specifications are:
DescriptionECDH-ES using Concat KDF and P-256ECDH-ES using Concat KDF and P-384ECDH-ES using Concat KDF and P-521ECDH-ES using Concat KDF and X25519ECDH-ES using Concat KDF and X448ECDH-ES using Concat KDF and P-256 and "A128KW" wrappingECDH-ES using Concat KDF and X25519 and "A128KW" wrappingECDH-ES using Concat KDF and P-384 and "A192KW" wrappingECDH-ES using Concat KDF and P-521 and "A256KW" wrappingECDH-ES using Concat KDF and X448 and "A256KW" wrapping
These registered COSE algorithms are likewise polymorphic,
because they do not include the curve name in the algorithm to be used with
the ephemeral key or the static key:
NameDescriptionECDH-ES + HKDF-256ECDH-ES w/ HKDF -- generate key directlyECDH-ES + HKDF-512ECDH-ES w/ HKDF -- generate key directlyECDH-SS + HKDF-256ECDH-SS w/ HKDF -- generate key directlyECDH-SS + HKDF-512ECDH-SS w/ HKDF -- generate key directlyECDH-ES + A128KWECDH-ES w/ HKDF and AES Key Wrap w/ 128-bit keyECDH-ES + A192KWECDH-ES w/ HKDF and AES Key Wrap w/ 192-bit keyECDH-ES + A256KWECDH-ES w/ HKDF and AES Key Wrap w/ 256-bit keyECDH-SS + A128KWECDH-SS w/ HKDF and AES Key Wrap w/ 128-bit keyECDH-SS + A192KWECDH-SS w/ HKDF and AES Key Wrap w/ 192-bit keyECDH-SS + A256KWECDH-SS w/ HKDF and AES Key Wrap w/ 256-bit key
Descriptions of fully-specified COSE versions of these algorithms
using combinations discussed by the working group
that could be registered by future specifications are:
DescriptionECDH-ES using P-256 w/ HKDF -- generate key directlyECDH-ES using X25519 w/ HKDF -- generate key directlyECDH-ES using P-521 w/ HKDF -- generate key directlyECDH-ES using X448 w/ HKDF -- generate key directlyECDH-SS using P-256 w/ HKDF -- generate key directlyECDH-SS using X25519 w/ HKDF -- generate key directlyECDH-SS using P-521 w/ HKDF -- generate key directlyECDH-SS using X448 w/ HKDF -- generate key directlyECDH-ES using P-256 w/ HKDF and AES Key Wrap w/ 128-bit keyECDH-ES using X25519 w/ HKDF and AES Key Wrap w/ 128-bit keyECDH-ES using P-384 w/ HKDF and AES Key Wrap w/ 192-bit keyECDH-ES using P-521 w/ HKDF and AES Key Wrap w/ 256-bit keyECDH-ES using X448 w/ HKDF and AES Key Wrap w/ 256-bit keyECDH-SS using P-256 w/ HKDF and AES Key Wrap w/ 128-bit keyECDH-SS using X25519 w/ HKDF and AES Key Wrap w/ 128-bit keyECDH-SS using P-384 w/ HKDF and AES Key Wrap w/ 192-bit keyECDH-SS using P-521 w/ HKDF and AES Key Wrap w/ 256-bit keyECDH-SS using X448 w/ HKDF and AES Key Wrap w/ 256-bit key
[[ to be removed by the RFC Editor before publication as an RFC ]]
-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,
Stephen Farrell,
Ilari Liusvaara,
Tobias Looker,
Neil Madden,
John Mattsson,
Jeremy O'Donoghue,
Anders Rundgren,
Göran Selander,
Filip Skokan,
Oliver Terbu,
Hannes Tschofenig,
and
David Waite
for their contributions to this specification.