Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE

Internet-Draft	PQ KEM for JOSE and COSE	March 2024
Reddy, et al.	Expires 4 September 2024	[Page]

1. Introduction

Quantum computing is no longer perceived as a conjecture of computational sciences and theoretical physics. Considerable research efforts and enormous corporate and government funding for the development of practical quantum computing systems are being invested currently. As such, as quantum technology advances, there is the potential for future quantum computers to have a significant impact on current cryptographic systems.¶

Researchers have developed Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) to provide secure key establishment resistant against an adversary with access to a quantum computer.¶

As the National Institute of Standards and Technology (NIST) is still in the process of selecting the new post-quantum cryptographic algorithms that are secure against both quantum and classical computers, the purpose of this document is to propose a PQ-KEMs to protect the confidentiality of content encrypted using JOSE and COSE against the quantum threat.¶

Although this mechanism could thus be used with any PQ-KEM, this document focuses on Module-Lattice-based Key Encapsulation Mechanisms (ML-KEMs). ML-KEM is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's ML-KEM public key. Three parameters sets for ML-KEMs are specified by [FIPS203-ipd]. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.¶

2. Conventions and Definitions

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.¶

This document makes use of the terms defined in [I-D.ietf-pquip-pqt-hybrid-terminology]. The following terms are repeately used in this specification:¶

KEM: Key Encapsulation Mechanism¶
PQ-KEM: Post-Quantum Key Encapsulation Mechanism¶
CEK: Content Encryption Key¶
ML-KEM: Module-Lattice-based Key Encapsulation Mechanism¶

For the purposes of this document, it is helpful to be able to divide cryptographic algorithms into two classes:¶

"Traditional Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms. In the context of JOSE, examples of traditional key exchange algorithms include Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090] [RFC8037]. In the context of COSE, examples of traditional key exchange algorithms include Ephemeral-Static (ES) DH and Static-Static (SS) DH [RFC9052].¶

"Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms. Examples of Post-Quantum Algorithm include ML-KEM.¶

2.1. Key Encapsulation Mechanisms

For the purposes of this document, we consider a Key Encapsulation Mechanism (KEM) to be any asymmetric cryptographic scheme comprised of algorithms satisfying the following interfaces [PQCAPI].¶

def kemKeyGen() -> (pk, sk)¶
def kemEncaps(pk) -> (ct, ss)¶
def kemDecaps(ct, sk) -> ss¶

where pk is public key, sk is secret key, ct is the ciphertext representing an encapsulated key, and ss is shared secret.¶

KEMs are typically used in cases where two parties, hereby refereed to as the "encapsulater" and the "decapsulater", wish to establish a shared secret via public key cryptography, where the decapsulater has an asymmetric key pair and has previously shared the public key with the encapsulater.¶

3. Design Rationales

Section 4.6 of the JSON Web Algorithms (JWA) specification, see [RFC7518], defines two ways of using a key agreement:¶

When Direct Key Agreement is employed, the shared secret established through the Traditional Algorithm will be the content encryption key (CEK).¶
When Key Agreement with Key Wrapping is employed, the shared secret established through the Traditional Algorithm will wrap the CEK.¶

For efficient use with multiple recipient the key wrap approach is used since the content can be encrypted once with the CEK but each CEK is encrypted per recipient. Similarly, Section 8.5.4 and Section 8.5.5 of COSE [RFC9052] define the Direct Key Agreement and Key Agreement with Key Wrap, respectively. This document proposes the use of PQ-KEMs for these two modes.¶

It is essential to note that in the PQ-KEM, one needs to apply Fujisaki-Okamoto [FO] transform or its variant [HHK] on the PQC KEM part to ensure that the overall scheme is IND-CCA2 secure, as mentioned in [I-D.ietf-tls-hybrid-design]. The FO transform is performed using the KDF such that the PQC KEM shared secret achieved is IND-CCA2 secure. As a consequence, one can re-use PQC KEM public keys but there is an upper bound that must be adhered to.¶

Note that during the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that incorporate both types of algorithms until the post-quantum algorithms are fully trusted. HPKE is an KEM that can be extended to support hybrid post-quantum KEMs and the specifications for the use of HPKE with JOSE and COSE are described in [I-D.ietf-rha-jose-hpke-encrypt] and [I-D.ietf-cose-hpke], respectively.¶

4. KEM PQC Algorithms

The National Institute of Standards and Technology (NIST) started a process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms, as seen here. Said process has reached its first announcement in July 5, 2022, which stated which candidates to be standardized for KEM:¶

Key Encapsulation Mechanisms (KEMs): CRYSTALS-Kyber: ML-KEM, previously known as Kyber, is a module learning with errors (MLWE)-based KEM. Three security levels have been defined in the NIST PQC Project, namely Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256, respectively.¶

NIST announced as well that they will be opening a fourth round to standardize an alternative KEM, and a call for new candidates for a post-quantum signature algorithm.¶

4.1. ML-KEM

ML-KEM offers several parameter sets with varying levels of security and performance trade-offs. This document specifies the use of the ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-KEM key generation, encapsulation and decaspulation functions are defined in [I-D.cfrg-schwabe-kyber]. The main security property for KEMs standardized in the NIST Post-Quantum Cryptography Standardization Project is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2) (see Section 10.2 of [I-D.ietf-pquip-pqc-engineers]). The public/private key sizes, ciphertext key size, and PQ security levels of ML-KEM are detailed in Section 12 of [I-D.ietf-pquip-pqc-engineers].¶

4.2. PQ-KEM Encapsulation

The encapsulation process is as follows:¶

Generate an inital shared secret SS' and the associated ciphertext CT using the KEM encapsulation function and the recipient's public key recipPubKey.¶

          (SS', CT) = kemEncaps(recipPubKey)

Derive a final shared secret SS of length SSLen bytes from the initial shared secret SS' using the underlying key derivation function:¶

          SS = KDF(SS', SSLen)

TBD: Discuss use of JOSE/COSE context specific data.¶

In Direct Key Agreement mode, the output of the KDF MUST be a key of the same length as that used by encryption algorithm. In Key Agreement with Key Wrapping mode, the output of the KDF MUST be a key of the length needed for the specified key wrap algorithm.¶

When Direct Key Agreement is employed, SS is the CEK. When Key Agreement with Key Wrapping is employed, SS is used to wrap the CEK.¶

4.3. PQ-KEM Decapsulation

The decapsulation process is as follows:¶

Decapsulate the ciphertext CT using the KEM decapsulation function and the recipient's private key to retrieve the initial shared secret SS':¶

          SS' = kemDecaps(recipPrivKey, CT)

If the decapsulation operation outputs an error, output "decryption error", and stop.

Derive the final shared secret SS of length SSLen bytes from the inital secret SS' using the underlying key derivation function:¶

          SS = KDF(SS', SSLen)

5. Post-quantum KEM in JOSE

As explained in Section 3 JWA defines two ways to use public key cryptography with JWE:¶

Direct Key Agreement¶
Key Agreement with Key Wrapping¶

This specification describes these two modes of use for PQ-KEM in JWE. Unless otherwise stated, no changes to the procedures described in [RFC7516] have been made.¶

If the 'alg' header parameter is set to the 'PQ-Direct' value, a PQ-KEM is used in Direct Key Agreement mode; otherwise, if the PQ-KEM is used in Key Agreement with Key Wrapping mode. See Section 10 for the IANA registration of this new algorithm value.¶

5.1. Direct Key Agreement

The "alg" header parameter MUST be set to "PQ-Direct". The "enc" (Encryption Algorithm) header parameter MUST be a PQ-KEM algorithm chosen from the JSON Web Signature and Encryption Algorithms registry defined in [JOSE-IANA]. Both header parameters, "alg" and "enc", MUST be placed in the JWE Protected Header.¶
The CEK will be generated using the process explained in Section 4.2. Subsequently, the plaintext will be encrypted using the CEK, as detailed in Step 15 of Section 5.1 of [RFC7516].¶
The JWE Ciphertext MUST include the concatenation of the output ('ct') from the PQ-KEM algorithm, encoded using base64url, along with the base64url-encoded ciphertext output obtained by encrypting the plaintext using the CEK. This encryption process corresponds to step 15 of [RFC7518].¶
The recipient MUST separate the 'ct' (output from the PQ-KEM algorithm) from the JWE Ciphertext to decode it and then use it to derive the CEK using the process defined in Section 4.3. The ciphertext sizes of ML-KEMs are discussed in Section 12 of [I-D.ietf-pquip-pqc-engineers].¶
The JWE Encrypted Key MUST be absent.¶

5.2. Key Agreement with Key Wrapping

The derived key is generated using the process explained in Section 4.2 and used to encrypt the CEK.¶
The JWE Encrypted Key MUST include the concatenation of the output ('ct') from the PQ-KEM algorithm, encoded using base64url, along with the base64url-encoded encrypted CEK.¶
The 'enc' (Encryption Algorithm) header parameter MUST specify a content encryption algorithm from the JSON Web Signature and Encryption Algorithms registry, as defined in [JOSE-IANA].¶
The recipient MUST separate the 'ct' (output from the PQ KEM Encaps algorithm) from the JWE Encrypted Key to decode it. Subsequently, it is used to derive the key, through the process defined in Section 4.3. The derived key will then be used to decrypt the CEK.¶

6. Post-Quantum KEM in COSE

This specification supports two uses of PQ-KEM in COSE, namely¶

PQ-KEM in a single recipient setup. This use case utilizes a one layer COSE structure.¶
PQ-KEM in a multiple recipient setup. This use case requires a two layer COSE structure.¶

6.1. Single Recipient / One Layer Structure

With the one layer structure the information carried inside the COSE_recipient structure is embedded inside the COSE_Encrypt0.¶

The CEK will be generated using the process explained in Section 4.2. Subsequently, the plaintext will be encrypted using the CEK. The resulting ciphertext is either included in the COSE_Encrypt0 or is detached. If a payload is transported separately then it is called "detached content". A nil CBOR object is placed in the location of the ciphertext. See Section 5 of [RFC9052] for a description of detached payloads.¶

The sender MUST set the alg parameter in the protected header, which indicates the use of PQ-KEM.¶

Although the use of the 'kid' parameter in COSE_Encrypt0 is discouraged by [RFC9052], this documents RECOMMENDS the use of the 'kid' parameter (or other parameters) to explicitly identify the recipient public key used by the sender. If the COSE_Encrypt0 contains the 'kid' then the recipient may use it to select the appropriate private key.¶

6.2. Key Agreement with Key Wrapping

With the two layer structure the PQ-KEM information is conveyed in the COSE_recipient structure, i.e. one COSE_recipient structure per recipient.¶

In this approach the following layers are involved:¶

Layer 0 (corresponding to the COSE_Encrypt structure) contains the content (plaintext) encrypted with the CEK. This ciphertext may be detached, and if not detached, then it is included in the COSE_Encrypt structure.¶
Layer 1 (corresponding to a recipient structure) contains parameters needed for PQ-KEM to generate a shared secret used to encrypt the CEK. This layer conveys the concatenation of the output ('ct') from the PQ KEM Encaps algorithm and encrypted CEK in the encCEK structure. The unprotected header MAY contain the kid parameter to identify the static recipient public key the sender has been using with PQ-KEM.¶

This two-layer structure is used to encrypt content that can also be shared with multiple parties at the expense of a single additional encryption operation. As stated above, the specification uses a CEK to encrypt the content at layer 0.¶

7. JOSE Ciphersuite Registration

This specification registers a number of PQ-KEM ciphersuites for use with JOSE. A ciphersuite is a group of algorithms, often sharing component algorithms such as hash functions, targeting a security level.¶

An PQ-KEM ciphersuite, is composed of the following choices:¶

PQ-KEM Algorithm¶
KDF Algorithm¶
AEAD Algorithm¶

All security levels of ML-KEM internally utilize SHA3-256, SHA3-512, SHAKE256, and SHAKE512. This internal usage influences the selection of the Key Derivation Function (KDF) within this document.¶

ML-KEM-512 MUST be used with a KDF capable of outputting a key with at least 128 bits of security and with a key wrapping algorithm with a key length of at least 128 bits.¶

ML-KEM-768 MUST be used with a KDF capable of outputting a key with at least 192 bits of security and with a key wrapping algorithm with a key length of at least 192 bits.¶

ML-KEM-1024 MUST be used with a KDF capable of outputting a key with at least 256 bits of security and with a key wrapping algorithm with a key length of at least 256 bits.¶

For readability the algorithm ciphersuites labels are built according to the following scheme:¶

PQ-<PQ-KEM>-<KDF>-<AEAD>

In Direct key agreement, the parameter "enc" MUST be specified, and its value MUST be one of the values specified in Figure 1. (Note that future specifications MAY extend the list of algorithms.)¶

 +===============================+===================================+
 | alg                           | Description                       |
 +===============================+===================================+
 | PQ-MLKEM512-SHA3-256-AES128   | ML-KEM-512 + SHA3-256 + AES128    |
 +===============================+===================================+
 | PQ-MLKEM768-SHA3-384-AES256   | ML-KEM-768 + SHA3-384 + AES256    |
 +===============================+===================================+
 | PQ-MLKEM1024-SHA3-512-AES256  | ML-KEM-1024 + SHA3-512 + AES256   |
 +===============================+===================================+

Figure 1: Direct Key Agreement: Algorithms.

In Key Agreement with Key Wrapping, the parameter "alg" MUST be specified, and its value MUST be one of the values specified in the table above.¶

The specification allows a small number of "known good" PQ-KEM ciphersuites instead of allowing arbitrary combinations of PQC algorithms, HKDF and AEAD Algorithms. It follows the recent trend in protocols to only allow a small number of "known good" configurations that make sense, instead of allowing arbitrary combinations of individual configuration choices that may interact in dangerous ways.¶

8. COSE Ciphersuite Registration

Figure 2 maps the JOSE algorithm names to the COSE algorithm values (for the PQ-KEM ciphersuites defined by this document).¶

+===============================+=========+=================================+=============+
| JOSE                          | COSE ID | Description                     | Recommended |
+===============================+=========+======================---========+=============+
| PQ-MLKEM512-SHA3-256-AES128   | TBD1    | ML-KEM-512 + SHA3-256 + AES128  | No          |
+-------------------------------+---------+---------------------------------+-------------+
| PQ-MLKEM768-SHA3-384-AES256   | TBD2    | ML-KEM-768 + SHA3-384 + AES256  | No          |
+-------------------------------+---------+---------------------------------+-------------+
| PQ-MLKEM768-SHA3-512-AES256   | TBD3    | ML-KEM-1024 + SHA3-512 + AES256 | No          |
+-------------------------------+---------+---------------------------------+-------------+

Figure 2: Mapping between JOSE and COSE PQ-KEM Ciphersuites.

10. IANA Considerations

10.1. JOSE

The following entries are added to the "JSON Web Signature and Encryption Algorithms" registry:¶

Algorithm Name: PQ-Direct¶
Algorithm Description: Post Quantum Direct Key Agreement.¶
Algorithm Usage Location(s): "alg"¶
JOSE Implementation Requirements: Optional¶
Change Controller: IESG¶
Specification Document(s): [[TBD: This RFC]]¶
Algorithm Analysis Documents(s): TODO¶
Algorithm Name: PQ-MLKEM512-SHA3-256-AES128¶
Algorithm Description: Cipher suite for PQ-KEM that uses ML-KEM-512 PQ-KEM, the SHA3-256 KDF and the AES-128-GCM AEAD.¶
Algorithm Usage Location(s): "alg, enc"¶
JOSE Implementation Requirements: Optional¶
Change Controller: IESG¶
Specification Document(s): [[TBD: This RFC]]¶
Algorithm Analysis Documents(s): TODO¶
Algorithm Name: PQ-MLKEM768-SHA3-384-AES256¶
Algorithm Description: Cipher suite for PQ-KEM that uses ML-KEM-768 PQ-KEM, the SHA3-384 KDF and the AES-256-GCM AEAD.¶
Algorithm Usage Location(s): "alg, enc"¶
JOSE Implementation Requirements: Optional¶
Change Controller: IESG¶
Specification Document(s): [[TBD: This RFC]]¶
Algorithm Analysis Documents(s): TODO¶
Algorithm Name: PQ-MLKEM1024-SHA3-512-AES256¶
Algorithm Description: Cipher suite for PQ-KEM that uses ML-KEM-1024 PQ-KEM, the SHA3-512 KDF and the AES-256-GCM AEAD.¶
Algorithm Usage Location(s): "alg, enc"¶
JOSE Implementation Requirements: Optional¶
Change Controller: IESG¶
Specification Document(s): [[TBD: This RFC]]¶
Algorithm Analysis Documents(s): TODO¶

10.2. COSE

The following has to be added to the "COSE Algorithms" registry:¶

Name: PQ-MLKEM512-SHA3-256-AES128¶
Value: TBD1¶
Description: Cipher suite for PQ-KEM that uses ML-KEM-512 PQ-KEM, the SHA3-256 KDF and the AES-128-GCM AEAD.¶
Reference: This document (TBD)¶
Recommended: No¶
Name: PQ-MLKEM768-SHA3-384-AES256¶
Value: TBD2¶
Description: Cipher suite for PQ-KEM that uses ML-KEM-768 PQ-KEM, the SHA3-384 KDF and the AES-256-GCM AEAD.¶
Reference: This document (TBD)¶
Recommended: No¶
Name: PQ-MLKEM1024-SHA3-512-AES256¶
Value: TBD3¶
Description: Cipher suite for PQ-KEM that uses ML-KEM-1024 PQ-KEM, the SHA3-512 KDF and the AES-256-GCM AEAD.¶
Reference: This document (TBD)¶
Recommended: No¶

References

Normative References

[JOSE-IANA]: IANA, "JSON Web Signature and Encryption Algorithms", n.d., <https://www.iana.org/assignments/jose/jose.xhtml>.
[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/rfc/rfc2119>.
[RFC7516]: Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/rfc/rfc7516>.
[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/rfc/rfc8174>.

Informative References

[FIPS203-ipd]: "Module-Lattice-based Key-Encapsulation Mechanism Standard", <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf>.
[FO]: "Secure Integration of Asymmetric and Symmetric Encryption Schemes", <https://link.springer.com/article/10.1007/s00145-011-9114-1>.
[HHK]: "A Modular Analysis of the Fujisaki-Okamoto Transformation", <https://link.springer.com/chapter/10.1007/978-3-319-70500-2_12>.
[I-D.cfrg-schwabe-kyber]: Schwabe, P. and B. Westerbaan, "Kyber Post-Quantum KEM", Work in Progress, Internet-Draft, draft-cfrg-schwabe-kyber-04, 2 January 2024, <https://datatracker.ietf.org/doc/html/draft-cfrg-schwabe-kyber-04>.
[I-D.ietf-cose-hpke]: Tschofenig, H., Steele, O., Daisuke, A., and L. Lundblade, "Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)", Work in Progress, Internet-Draft, draft-ietf-cose-hpke-07, 22 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-07>.
[I-D.ietf-pquip-pqc-engineers]: Banerjee, A., Reddy.K, T., Schoinianakis, D., and T. Hollebeek, "Post-Quantum Cryptography for Engineers", Work in Progress, Internet-Draft, draft-ietf-pquip-pqc-engineers-03, 22 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-engineers-03>.
[I-D.ietf-pquip-pqt-hybrid-terminology]: D, F., "Terminology for Post-Quantum Traditional Hybrid Schemes", Work in Progress, Internet-Draft, draft-ietf-pquip-pqt-hybrid-terminology-02, 2 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-02>.
[I-D.ietf-rha-jose-hpke-encrypt]: "*** BROKEN REFERENCE ***".
[I-D.ietf-tls-hybrid-design]: Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-09, 7 September 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-09>.
[PQCAPI]: "PQC - API notes", <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf>.
[RFC6090]: McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/rfc/rfc6090>.
[RFC7518]: Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.
[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/rfc/rfc8037>.
[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/rfc/rfc9052>.