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)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 all 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.
This specification creates fully-specified algorithm identifiers for all 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 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-512Yes 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 algorithms are defined:
NameCOSE ValueDescriptionJOSE Implementation RequirementsCOSE RecommendedEd25519TBD (requested assignment -50)EdDSA using Ed25519 curveOptionalNoEd448TBD (requested assignment -51)EdDSA using Ed448 curveOptionalNo
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: IESG
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: IESG
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: IESG
Reference: Section 3.1 of RFC8037
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
Reference: of this document
Recommended: Yes
Name: ESP384
Value: TBD (requested assignment -48)
Description: ECDSA using P-384 curve and SHA-384
Reference: of this document
Recommended: Yes
Name: ESP512
Value: TBD (requested assignment -49)
Description: ECDSA using P-521 curve and SHA-512
Reference: of this document
Recommended: Yes
Name: Ed25519
Value: TBD (requested assignment -50)
Description: EdDSA using Ed25519 curve
Reference: of this document
Recommended: Yes
Name: Ed448
Value: TBD (requested assignment -51)
Description: EdDSA using Ed448 curve
Reference: of this document
Recommended: Yes
The following registrations are updated to change their status to Deprecated.
Name: ES256
Value: -7
Description: ECDSA w/ SHA-256
Reference: RFC 9053
Recommended: Deprecated
Name: ES384
Value: -35
Description: ECDSA w/ SHA-384
Reference: RFC 9053
Recommended: Deprecated
Name: ES512
Value: -36
Description: ECDSA w/ SHA-512
Reference: RFC 9053
Recommended: Deprecated
Name: EdDSA
Value: -8
Description: EdDSA
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 document.
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 document.
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 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.
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.
Each of these multiple algorithms must be independently fully specified.
The operations performed by each of them MUST NOT vary
when used alongside other algorithms.
So for instance, for JOSE, alg values
and enc values MUST each be fully specified,
and their behaviors MUST NOT depend upon one another.
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 is not a problem in practice, because RSA libraries accomodate
keys of different sizes without having to use different code.
Therefore, for example, there are not known cases in the wild where it would be useful
to have different algorithm identifiers for RSASSA-PKCS1-v1_5 with SHA-256 and 2048-bit keys
and RSASSA-PKCS1-v1_5 with SHA-256 and 4096-bit keys or 8192-bit keys.
Therefore, the RSA signature algorithms are not replaced by this specification.
The working group has discussed whether the
ECDH-ES key agreement algorithm
should be considered fully-specified or not,
because it can use ephemeral keys of different key types and algorithms.
Indeed, an implementation might work when ECDH-ES
is used with a ephemeral keys using the P-256 curve,
and not work when used with ephemeral keys using the
Ed25519 curve.
One way that protocols can handle this situation is to use a discovery mechanism
to declare what ephemeral key types are supported.
The alternative would be to introduce new fully-specified algorithm identifiers
for choices such as "ECDH-ES with the P-256 Curve", etc.
Feedback from deployers would be useful in determining
what actions this specification should take in this case.
All key encapsulation mechanisms (KEM) algorithms,
as described in ,
provide three functions: KeyGen(), Encapsulate(), and Decapsulate().
In order to consider a KEM algorithm fully specified,
there MUST be a single KDF used per KEM Algorithm.
For example, the HPKE KEM "0x0010 or DHKEM(P-256, HKDF-SHA256)",
as defined in , is fully specified,
because it uses a single elliptic curve (secp256r1) and
a single KDF (HKDF with SHA256), as described in .
Using fully-specified algorithm identifiers reduces the attack surface
relative to using polymorphic algorithm identifiers,
since it reduces the opportunity for attackers to choose algorithms.
The security considerations for ECDSA in ,
for EdDSA in , and
for ECDSA and EdDSA in apply.
PQC-APINational Institute of Standards and Technology (NIST)JOSE AlgorithmsIANACOSE AlgorithmsIANAOpenID Connect Discovery 1.0NAT.ConsultingYubicoindependentIllumilaWeb 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.comOneSpanjohan.verrept@onespan.com
[[ to be removed by the RFC Editor before publication as an RFC ]]
-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
John Bradley,
Brian Campbell,
Ilari Liusvarra,
Tobias Looker,
and
Filip Skokan
for their contributions to this specification.