Fully-Specified Algorithms for JOSE and COSE
draft-ietf-jose-fully-specified-algorithms-05
| Document | Type | Active Internet-Draft (jose WG) | |
|---|---|---|---|
| Authors | Michael B. Jones , Orie Steele | ||
| Last updated | 2024-08-17 | ||
| Replaces | draft-jones-jose-fully-specified-algorithms | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | Waiting for WG Chair Go-Ahead | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-jose-fully-specified-algorithms-05
JOSE Working Group M.B. Jones
Internet-Draft Self-Issued Consulting
Updates: 7518, 8037, 8152, 9053 (if approved) O. Steele
Intended status: Standards Track Transmute
Expires: 18 February 2025 17 August 2024
Fully-Specified Algorithms for JOSE and COSE
draft-ietf-jose-fully-specified-algorithms-05
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 2025.
Copyright Notice
Copyright (c) 2024 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Jones & Steele Expires 18 February 2025 [Page 1]
Internet-Draft Fully-Specified Algorithms August 2024
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation and Conventions . . . . . . . . . . 4
2. Fully-Specified Digital Signature Algorithm Identifiers . . . 4
2.1. Elliptic Curve Digital Signature Algorithm (ECDSA) . . . 4
2.2. Edwards-Curve Digital Signature Algorithm (EdDSA) . . . . 5
3. Fully-Specified Encryption . . . . . . . . . . . . . . . . . 6
3.1. Fully-Specified Computations Using Multiple Algorithms . 6
3.2. Analysis of Modes of Encryption . . . . . . . . . . . . . 6
3.2.1. Direct Encryption . . . . . . . . . . . . . . . . . . 7
3.2.2. Key Establishment with Direct Encryption . . . . . . 8
3.2.3. Two-Layer Encryption . . . . . . . . . . . . . . . . 11
3.3. Fully-Specified Encryption Algorithm Identifiers . . . . 14
3.3.1. Elliptic Curve Diffie-Hellman (ECDH) . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. JOSE Algorithms Registrations . . . . . . . . . . . . . . 15
4.1.1. Fully-Specified JOSE Algorithm Registrations . . . . 15
4.1.2. Deprecated Polymorphic JOSE Algorithm
Registrations . . . . . . . . . . . . . . . . . . . . 15
4.2. COSE Algorithms Registrations . . . . . . . . . . . . . . 15
4.2.1. Fully-Specified COSE Algorithm Registrations . . . . 15
4.2.2. Deprecated Polymorphic COSE Algorithm
Registrations . . . . . . . . . . . . . . . . . . . . 17
4.3. Updated Review Instructions for Designated Experts . . . 18
4.3.1. JSON Web Signature and Encryption Algorithms . . . . 18
4.3.2. COSE Algorithms . . . . . . . . . . . . . . . . . . . 18
4.4. Defining Deprecated and Prohibited . . . . . . . . . . . 19
5. Key Representations . . . . . . . . . . . . . . . . . . . . . 20
6. Notes on Algorithms Not Updated . . . . . . . . . . . . . . . 20
6.1. RSA Signing Algorithms . . . . . . . . . . . . . . . . . 20
6.2. ECDH Encryption Algorithms . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Inventory of Polymorphic ECDH Algorithms . . . . . . 23
A.1. Polymorphic ECDH JOSE Algorithms . . . . . . . . . . . . 23
A.2. Polymorphic ECDH COSE Algorithms . . . . . . . . . . . . 24
Appendix B. Document History . . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Jones & Steele Expires 18 February 2025 [Page 2]
Internet-Draft Fully-Specified Algorithms August 2024
1. Introduction
The IANA algorithm registries for JOSE [IANA.JOSE] and COSE
[IANA.COSE] 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),
hash functions, etc. 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 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 [RFC8414] uses negotiation parameters like these
(from an example in the specification):
"token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"]
OpenID Connect Discovery [OpenID.Discovery] likewise negotiates
supported algorithms using alg and enc values. W3C Web
Authentication [WebAuthn] and FIDO Client to Authenticator Protocol
(CTAP) [FIDO2] 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:
-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.
Jones & Steele Expires 18 February 2025 [Page 3]
Internet-Draft Fully-Specified Algorithms August 2024
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.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Fully-Specified Digital Signature Algorithm Identifiers
This section creates fully-specified digital signature algorithm
identifiers for all registered polymorphic JOSE and COSE algorithms
and their parameters.
2.1. Elliptic Curve Digital Signature Algorithm (ECDSA)
[RFC9053] 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 [RFC9053]. (The corresponding JOSE registrations
in [RFC7518] are full-specified.)
The following fully-specified COSE ECDSA algorithms are defined:
Jones & Steele Expires 18 February 2025 [Page 4]
Internet-Draft Fully-Specified Algorithms August 2024
+========+==================+===================+=============+
| Name | COSE Value | Description | COSE |
| | | | Recommended |
+========+==================+===================+=============+
| ESP256 | TBD (requested | ECDSA using P-256 | Yes |
| | assignment -9) | curve and SHA-256 | |
+--------+------------------+-------------------+-------------+
| ESP384 | TBD (requested | ECDSA using P-384 | Yes |
| | assignment -48) | curve and SHA-384 | |
+--------+------------------+-------------------+-------------+
| ESP512 | TBD (requested | ECDSA using P-521 | Yes |
| | assignment -49) | curve and SHA-512 | |
+--------+------------------+-------------------+-------------+
| ESB256 | TBD (requested | ECDSA using | No |
| | assignment -261) | BrainpoolP256r1 | |
| | | curve and SHA-256 | |
+--------+------------------+-------------------+-------------+
| ESB320 | TBD (requested | ECDSA using | No |
| | assignment -262) | BrainpoolP320r1 | |
| | | curve and SHA-384 | |
+--------+------------------+-------------------+-------------+
| ESB384 | TBD (requested | ECDSA using | No |
| | assignment -263) | BrainpoolP384r1 | |
| | | curve and SHA-384 | |
+--------+------------------+-------------------+-------------+
| ESB512 | TBD (requested | ECDSA using | No |
| | assignment -264) | BrainpoolP512r1 | |
| | | curve and SHA-512 | |
+--------+------------------+-------------------+-------------+
Table 1: ECDSA Algorithm Values
2.2. Edwards-Curve Digital Signature Algorithm (EdDSA)
[RFC8037] defines the current use of the Edwards-Curve Digital
Signature Algorithm (EdDSA) by JOSE and [RFC9053] defines its current
use by COSE. Both register polymorphic EdDSA algorithm identifiers.
The following fully-specified JOSE and COSE EdDSA algorithms are
defined:
Jones & Steele Expires 18 February 2025 [Page 5]
Internet-Draft Fully-Specified Algorithms August 2024
+=======+============+=============+================+=============+
|Name | COSE Value | Description | JOSE | COSE |
| | | | Implementation | Recommended |
| | | | Requirements | |
+=======+============+=============+================+=============+
|Ed25519| TBD | EdDSA using | Optional | Yes |
| | (requested | Ed25519 | | |
| | assignment | curve | | |
| | -50) | | | |
+-------+------------+-------------+----------------+-------------+
|Ed448 | TBD | EdDSA using | Optional | Yes |
| | (requested | Ed448 curve | | |
| | assignment | | | |
| | -51) | | | |
+-------+------------+-------------+----------------+-------------+
Table 2: EdDSA Algorithm Values
3. Fully-Specified Encryption
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
[RFC7516] and COSE Encrypt as described in [RFC9052].
3.1. Fully-Specified Computations Using Multiple Algorithms
Both JOSE and COSE have operations that take multiple algorithms as
parameters. Encrypted objects in JOSE [RFC7516] 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.
3.2. Analysis of Modes of Encryption
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.
Jones & Steele Expires 18 February 2025 [Page 6]
Internet-Draft Fully-Specified Algorithms August 2024
* 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
algorithms, since complete replacements for them are not provided.
It does register a small set of new fully-specified encryption
algorithms, so that polymorphic encryption algorithms need not be
used.
The following sections describe what fully specified means for each
mode. They also register at least one fully-specified algorithm for
each mode, when one was not already available.
3.2.1. Direct Encryption
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.
Jones & Steele Expires 18 February 2025 [Page 7]
Internet-Draft Fully-Specified Algorithms August 2024
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.
Key Wrapping algorithms impose additional implicit constraints on AAD
and IV.
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",
...
}
3.2.2. Key Establishment with Direct Encryption
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)
Jones & Steele Expires 18 February 2025 [Page 8]
Internet-Draft Fully-Specified Algorithms August 2024
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, can be used to
provide a common interface for deriving shared secrets, regardless of
key type.
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.
Jones & Steele Expires 18 February 2025 [Page 9]
Internet-Draft Fully-Specified Algorithms August 2024
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
recipients supported algorithms.
In JOSE and COSE, key representations can support communicating the
algorithm which a recipient supports for a given key. It is
considered a best practice to only support one algorithm during the
lifetime of a key.
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 identifier. In the context of the example above, the
missing explicit parameters are curve name and KDF name. If the KDF
requires additional parameters, they need to be present.
To convey a fully-specified Key Establishment with Direct Encryption
algorithm in JOSE, the "alg" value MUST be "dir", and the "enc" value
MUST be fully specified, specifying all essential parameters for both
key establishment and symmetric encryption. For example: "ECDH-ES
using P-256 and Concat-KDF with A128GCM" or "ECDH-ES using X25519 and
Concat-KDF with A256GCM".
Jones & Steele Expires 18 February 2025 [Page 10]
Internet-Draft Fully-Specified Algorithms August 2024
To convey a fully-specified Key Establishment with Direct Encryption
algorithm in COSE, the "alg" value MUST specify all essential
parameters for both key establishment and symmetric encryption. For
example: "ECDH-ES using P-256 and HKDF SHA-256 with A128GCM" or
"ECDH-ES using X25519 HKDF SHA-512 wit A256GCM".
Fully-specified Key Establishment with Direct Encryption algorithms
enable the sender and receiver to agree on all algorithms needed to
encrypt and decrypt a message using a single algorithm identifier.
3.2.3. Two-Layer Encryption
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 encrypted content encryption key is generated
through 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 was 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)
Jones & Steele Expires 18 February 2025 [Page 11]
Internet-Draft Fully-Specified Algorithms August 2024
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.
Jones & Steele Expires 18 February 2025 [Page 12]
Internet-Draft Fully-Specified Algorithms August 2024
When using Two-Layer Encryption, the ciphertext is not only the
output of symmetric encryption, but also includes and/or 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 algorithms are 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 which can only
be used to encrypt to a single recipient.
Example of a decoded JWE Protected Header, for Key Agreement with
ECDH-ES:
{
"alg": "ECDH-ES",
"enc": "A256GCM",
...
}
Example of a decoded JWE Protected Header, for Key Agreement using
ECDH-ES and AES-KeyWrap with AES-GCM:
{
"alg": "ECDH-ES+A128KW",
"enc": "A128GCM",
...
}
However, despite containing both the key establishment algorithm and
a content encryption algorithm, the examples above are not fully
specified.
To make a Two-Layer Encryption algorithm fully specified, all
security relevant details need to be encoded in the algorithm
identifiers directly or be defined by the other algorithm. In the
context of the examples above, the missing explicit parameters are
the curve name for the ephemeral key in both cases and for ECDH-ES,
the keydatalen KDF parameter.
Jones & Steele Expires 18 February 2025 [Page 13]
Internet-Draft Fully-Specified Algorithms August 2024
To convey a fully-specified Two-Layer Encryption algorithm in JOSE,
the "alg" value MUST explicitly specify all essential parameters for
key establishment and key wrapping or have them be specified by the
accompanying "enc" value. For example: "ECDH-ES using Concat KDF and
P-256" or "ECDH-ES using Concat KDF and P-256 and "A128KW" wrapping".
The keydatalen KDF parameter value for ECDH-ES is determined from the
"enc" value, as described in Section 4.6.2 of [RFC7518].
To convey a fully-specified Two-Layer Encryption algorithm in COSE,
the outer "alg" value MUST specify all essential parameters for key
establishment and key wrapping. For example: "ECDH-ES using P-256 w/
HKDF" or "ECDH-ES using P-256 w/ HKDF and AES Key Wrap w/ 128-bit
key".
In COSE, preventing cross-mode attacks, such as those described in
[RFC9459], 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.
3.3. Fully-Specified Encryption Algorithm Identifiers
3.3.1. Elliptic Curve Diffie-Hellman (ECDH)
[RFC7518] defines the current use of Elliptic Curve Diffie-Hellman
(ECDH) by JOSE. Likewise, [RFC9053] defines the current use of
Elliptic Curve Diffie-Hellman (ECDH) by COSE. As described in
Appendix A, both sets of registered ECDH algorithms are polymorphic.
While Appendix A describes possible fully-specified ECDH algorithms
that could be registered for JOSE and COSE, the working group decided
to leave decisions about which fully-specified ECDH algorithms to
register to future specifications, if needed.
4. IANA Considerations
Jones & Steele Expires 18 February 2025 [Page 14]
Internet-Draft Fully-Specified Algorithms August 2024
4.1. JOSE Algorithms Registrations
This section registers the following values in the IANA "JSON Web
Signature and Encryption Algorithms" registry [IANA.JOSE] established
by [RFC7515].
4.1.1. Fully-Specified JOSE Algorithm Registrations
* Algorithm Name: Ed25519
* Algorithm Description: EdDSA using Ed25519 curve
* Algorithm Usage Locations: alg
* JOSE Implementation Requirements: Optional
* Change Controller: IETF
* Reference: Section 2.2 of [[ this specification ]]
* Algorithm Analysis Document(s): [RFC8032]
* Algorithm Name: Ed448
* Algorithm Description: EdDSA using Ed448 curve
* Algorithm Usage Locations: alg
* JOSE Implementation Requirements: Optional
* Change Controller: IETF
* Reference: Section 2.2 of [[ this specification ]]
* Algorithm Analysis Document(s): [RFC8032]
4.1.2. Deprecated Polymorphic JOSE Algorithm Registrations
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: Section 2.2 of [[ this specification ]]
* Algorithm Analysis Document(s): [RFC8032]
4.2. COSE Algorithms Registrations
This section registers the following values in the IANA "COSE
Algorithms" registry [IANA.COSE].
4.2.1. Fully-Specified COSE Algorithm Registrations
* Name: ESP256
* Value: TBD (requested assignment -9)
* Description: ECDSA using P-256 curve and SHA-256
Jones & Steele Expires 18 February 2025 [Page 15]
Internet-Draft Fully-Specified Algorithms August 2024
* Capabilities: [kty]
* Change Controller: IETF
* Reference: Section 2.1 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: Section 2.1 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: Section 2.1 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: Section 2.1 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: Section 2.1 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: Section 2.1 of [[ this specification ]]
Jones & Steele Expires 18 February 2025 [Page 16]
Internet-Draft Fully-Specified Algorithms August 2024
* Recommended: No
* Name: ESB512
* Value: TBD (requested assignment -264)
* Description: ECDSA using BrainpoolP512r1 curve and SHA-512
* Capabilities: [kty]
* Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]]
* Recommended: No
* Name: Ed25519
* Value: TBD (requested assignment -50)
* Description: EdDSA using Ed25519 curve
* Capabilities: [kty]
* Change Controller: IETF
* Reference: Section 2.2 of [[ this specification ]]
* Recommended: Yes
* Name: Ed448
* Value: TBD (requested assignment -51)
* Description: EdDSA using Ed448 curve
* Capabilities: [kty]
* Change Controller: IETF
* Reference: Section 2.2 of [[ this specification ]]
* Recommended: Yes
4.2.2. Deprecated Polymorphic COSE Algorithm Registrations
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
Jones & Steele Expires 18 February 2025 [Page 17]
Internet-Draft Fully-Specified Algorithms August 2024
* 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
4.3. Updated Review Instructions for Designated Experts
4.3.1. JSON Web Signature and Encryption Algorithms
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 [IANA.JOSE] in
Section 7.1 of [RFC7518] have been updated to include an additional
review criterion:
* Only fully-specified algorithm identifiers may be registered.
Polymorphic algorithm identifiers must not be registered.
4.3.2. COSE Algorithms
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 [IANA.COSE] in Section 10.4 of [RFC9053] have
been updated to include an additional review criterion:
* Only fully-specified algorithm identifiers may be registered.
Polymorphic algorithm identifiers must not be registered.
Jones & Steele Expires 18 February 2025 [Page 18]
Internet-Draft Fully-Specified Algorithms August 2024
4.4. Defining Deprecated and Prohibited
The terms "Deprecated" and "Prohibited" as used by JOSE and COSE
registrations are currently undefined. Furthermore, while in
[RFC7518] JOSE specifies that both "Deprecated" and "Prohibited" can
be used, in [RFC8152] COSE specifies the use of "Deprecated" but not
"Prohibited". (Note that [RFC9053] did not carry the definitions of
the "Recommended" registry columns forward, so [RFC8152] 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 [IANA.JOSE] and in the "Recommended"
columns in the IANA COSE registries [IANA.COSE], these terms are
defined as follows:
Deprecated
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.
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.)
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
[RFC8996], 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.
Jones & Steele Expires 18 February 2025 [Page 19]
Internet-Draft Fully-Specified Algorithms August 2024
5. 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 [RFC8037],
except that the alg value would be Ed25519 rather than EdDSA, if
included.
6. Notes on Algorithms Not Updated
The working group has discussed some existing algorithms that are not
updated by this specification. This section discusses why they have
not been updated.
6.1. RSA Signing Algorithms
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 accommodate
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 versus 4096-bit keys
or 8192-bit keys. Therefore, the RSA signature algorithms are not
replaced by this specification.
That said, should it be useful at some point to have RSA algorithm
identifiers that are specific to the key size, a future specification
could always register them.
6.2. ECDH Encryption Algorithms
As discussed in Section 3.3.1 and Appendix A, 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.
Jones & Steele Expires 18 February 2025 [Page 20]
Internet-Draft Fully-Specified Algorithms August 2024
7. Security Considerations
Using fully-specified algorithm identifiers reduces the attack
surface relative to using polymorphic algorithm identifiers, since it
reduces the opportunity for attackers to choose insecure or
unexpected combinations of algorithms.
The security considerations for ECDSA in [RFC7518], for EdDSA in
[RFC8037], and for ECDSA and EdDSA in [RFC9053] apply.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
8.2. Informative References
Jones & Steele Expires 18 February 2025 [Page 21]
Internet-Draft Fully-Specified Algorithms August 2024
[FIDO2] Bradley, J., Hodges, J., Jones, M., Kumar, A., and J.
Johan, "Client to Authenticator Protocol (CTAP)", FIDO
Alliance Proposed Standard, 15 June 2021,
<https://fidoalliance.org/specs/fido-v2.1-ps-20210615/
fido-client-to-authenticator-protocol-v2.1-ps-
20210615.html>.
[IANA.COSE]
IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose/>.
[IANA.JOSE]
IANA, "JSON Object Signing and Encryption (JOSE)",
<https://www.iana.org/assignments/jose/>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,
"OpenID Connect Discovery 1.0", 8 November 2014,
<https://openid.net/specs/openid-connect-discovery-
1_0.html>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
[RFC9459] Housley, R. and H. Tschofenig, "CBOR Object Signing and
Encryption (COSE): AES-CTR and AES-CBC", RFC 9459,
DOI 10.17487/RFC9459, September 2023,
<https://www.rfc-editor.org/info/rfc9459>.
Jones & Steele Expires 18 February 2025 [Page 22]
Internet-Draft Fully-Specified Algorithms August 2024
[WebAuthn] Hodges, J., Jones, J.C., Jones, M., Kumar, A., and E.
Lundberg, "Web Authentication: An API for accessing Public
Key Credentials - Level 2", World Wide Web Consortium
(W3C) Recommendation, 8 April 2021,
<https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>.
Appendix A. Inventory of Polymorphic ECDH Algorithms
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.
A.1. Polymorphic ECDH JOSE Algorithms
These registered JOSE algorithms are polymorphic, because they do not
include the curve name in the algorithm to be used with the ephemeral
key:
+================+================================================+
| Name | Description |
+================+================================================+
| ECDH-ES | ECDH-ES using Concat KDF |
+----------------+------------------------------------------------+
| ECDH-ES+A128KW | ECDH-ES using Concat KDF and "A128KW" wrapping |
+----------------+------------------------------------------------+
| ECDH-ES+A192KW | ECDH-ES using Concat KDF and "A192KW" wrapping |
+----------------+------------------------------------------------+
| ECDH-ES+A256KW | ECDH-ES using Concat KDF and "A256KW" wrapping |
+----------------+------------------------------------------------+
Table 3: Polymorphic ECDH JOSE Algorithms
Descriptions of fully-specified JOSE versions of these algorithms
using combinations discussed by the working group that could be
registered by future specifications are:
Jones & Steele Expires 18 February 2025 [Page 23]
Internet-Draft Fully-Specified Algorithms August 2024
+===========================================================+
| Description |
+===========================================================+
| ECDH-ES using Concat KDF and P-256 |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and P-384 |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and P-521 |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and X25519 |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and X448 |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and P-256 and "A128KW" wrapping |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and X25519 and "A128KW" wrapping |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and P-384 and "A192KW" wrapping |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and P-521 and "A256KW" wrapping |
+-----------------------------------------------------------+
| ECDH-ES using Concat KDF and X448 and "A256KW" wrapping |
+-----------------------------------------------------------+
Table 4: Fully-Specified ECDH JOSE Algorithms
A.2. Polymorphic ECDH COSE Algorithms
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:
Jones & Steele Expires 18 February 2025 [Page 24]
Internet-Draft Fully-Specified Algorithms August 2024
+====================+==========================================+
| Name | Description |
+====================+==========================================+
| ECDH-ES + HKDF-256 | ECDH-ES w/ HKDF -- generate key directly |
+--------------------+------------------------------------------+
| ECDH-ES + HKDF-512 | ECDH-ES w/ HKDF -- generate key directly |
+--------------------+------------------------------------------+
| ECDH-SS + HKDF-256 | ECDH-SS w/ HKDF -- generate key directly |
+--------------------+------------------------------------------+
| ECDH-SS + HKDF-512 | ECDH-SS w/ HKDF -- generate key directly |
+--------------------+------------------------------------------+
| ECDH-ES + A128KW | ECDH-ES w/ HKDF and AES Key Wrap w/ |
| | 128-bit key |
+--------------------+------------------------------------------+
| ECDH-ES + A192KW | ECDH-ES w/ HKDF and AES Key Wrap w/ |
| | 192-bit key |
+--------------------+------------------------------------------+
| ECDH-ES + A256KW | ECDH-ES w/ HKDF and AES Key Wrap w/ |
| | 256-bit key |
+--------------------+------------------------------------------+
| ECDH-SS + A128KW | ECDH-SS w/ HKDF and AES Key Wrap w/ |
| | 128-bit key |
+--------------------+------------------------------------------+
| ECDH-SS + A192KW | ECDH-SS w/ HKDF and AES Key Wrap w/ |
| | 192-bit key |
+--------------------+------------------------------------------+
| ECDH-SS + A256KW | ECDH-SS w/ HKDF and AES Key Wrap w/ |
| | 256-bit key |
+--------------------+------------------------------------------+
Table 5: Polymorphic ECDH COSE Algorithms
Descriptions of fully-specified COSE versions of these algorithms
using combinations discussed by the working group that could be
registered by future specifications are:
Jones & Steele Expires 18 February 2025 [Page 25]
Internet-Draft Fully-Specified Algorithms August 2024
+==============================================================+
| Description |
+==============================================================+
| ECDH-ES using P-256 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-ES using X25519 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-ES using P-521 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-ES using X448 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-SS using P-256 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-SS using X25519 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-SS using P-521 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-SS using X448 w/ HKDF -- generate key directly |
+--------------------------------------------------------------+
| ECDH-ES using P-256 w/ HKDF and AES Key Wrap w/ 128-bit key |
+--------------------------------------------------------------+
| ECDH-ES using X25519 w/ HKDF and AES Key Wrap w/ 128-bit key |
+--------------------------------------------------------------+
| ECDH-ES using P-384 w/ HKDF and AES Key Wrap w/ 192-bit key |
+--------------------------------------------------------------+
| ECDH-ES using P-521 w/ HKDF and AES Key Wrap w/ 256-bit key |
+--------------------------------------------------------------+
| ECDH-ES using X448 w/ HKDF and AES Key Wrap w/ 256-bit key |
+--------------------------------------------------------------+
| ECDH-SS using P-256 w/ HKDF and AES Key Wrap w/ 128-bit key |
+--------------------------------------------------------------+
| ECDH-SS using X25519 w/ HKDF and AES Key Wrap w/ 128-bit key |
+--------------------------------------------------------------+
| ECDH-SS using P-384 w/ HKDF and AES Key Wrap w/ 192-bit key |
+--------------------------------------------------------------+
| ECDH-SS using P-521 w/ HKDF and AES Key Wrap w/ 256-bit key |
+--------------------------------------------------------------+
| ECDH-SS using X448 w/ HKDF and AES Key Wrap w/ 256-bit key |
+--------------------------------------------------------------+
Table 6: Fully-Specified ECDH COSE Algorithms
Appendix B. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]]
-05
Jones & Steele Expires 18 February 2025 [Page 26]
Internet-Draft Fully-Specified Algorithms August 2024
* 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
Jones & Steele Expires 18 February 2025 [Page 27]
Internet-Draft Fully-Specified Algorithms August 2024
* Created initial working group version based on draft-jones-jose-
fully-specified-algorithms-02.
Acknowledgements
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, and David Waite for their
contributions to this specification.
Authors' Addresses
Michael B. Jones
Self-Issued Consulting
Email: michael_b_jones@hotmail.com
URI: https://self-issued.info/
Orie Steele
Transmute
Email: orie@transmute.industries
Jones & Steele Expires 18 February 2025 [Page 28]