]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Vigil Security, LLC

Herndon, VA US housley@vigilsec.com

Security LAMPS Internet-Draft The DHKEM Algorithm is a one-pass (store-and-forward) mechanism for establishing keying data to a recipient using the recipient's Diffie-Hellman or elliptic curve Diffie-Hellman public key. This document defines a mechanism to wrap Ephemeral-Static (E-S) Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) such that it can be used in KEM interfaces within the Cryptographic Message Syntax (CMS). This is a sister document to RSA-KEM and simplifies future cryptographic protocol design by only needing to handle KEMs at the protocol level. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Cryptographic Message Syntax (CMS) enveloped-data content type and the CMS authenticated-enveloped-data content type support both key transport and key agreement algorithms to establish the key used to encrypt the content. In recent years, cryptographers have be specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for wrapping Diffie-Hellman Ephemeral-Static (E-S) Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) to fit the KEM interface for the CMS enveloped-data content type and the CMS authenticated-enveloped-data content type as defined in . This is a parallel mechanism to which does the same for RSA. The benefit is to allow forward-compatibility of older DH-based ciphers into new mechanisms that only support KEMs. A KEM algorithm is a one-pass (store-and-forward) mechanism for transporting random keying material to a recipient using the recipient's public key. The recipient's private key is needed to recover the random keying material, which is then treated as a pairwise shared secret between the originator and recipient. A KEM algorithm provides three functions:

• KeyGen() -> (pk, sk):

• Generate the public key (pk) and a private key (sk).

• Encapsulate(pk) -> (ct, ss):

• Given the recipient's public key (pk), produce a ciphertext (ct) to be passed to the recipient and shared secret (ss) for the originator.

• Decapsulate(sk, ct) -> ss:

• Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss) for the recipient.

To support a particular KEM algorithm, the CMS originator MUST implement Encapsulate(). To support a particular KEM algorithm, the CMS recipient MUST implement KeyGen() and Decapsulate(). The recipient's public key is usually carried in a certificate . This draft follows the DH-Based KEM (DHKEM) construction defined in whereby the Encapsulate() operation includes the generation of an ephemeral key and the usage of that key against the recipient's static public key.

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 when, and only when, they appear in all capitals, as shown here.

Cryptographic dependencies

Key Derivation Function A key derivation function (KDF):

• Extract(salt, ikm): Extract a pseudorandom key of fixed length keyLength bytes from input keying material ikm and an optional byte string salt.
• Expand(prk, info, L): Expand a pseudorandom key prk using optional string info into L bytes of output keying material.
• keyLength: The output size of the Extract() function in bytes.

(Elliptic Curve) Diffie Hellman An elliptic curve or finite field Diffie-Hellman group providing the following operations:

• GenerateKeyPair(): create a new DH key.
• DH(skX, pkY): Perform a non-interactive Diffie-Hellman exchange using the private key skX and public key pkY to produce a Diffie-Hellman shared secret of length Ndh. This function can raise a ValidationError as described in Section 7.1.4.

DH-Based KEM (DHKEM) This is a straightforward application of the DHKEM construction from section 4.1 which is to be used unmodified. CMS encrypt operations performed by the sender are to use Encap(pkR). CMS decrypt operations performed by the received are to use Decap(enc, skR). The authenticated modes, AuthEncap(pkR, skS) and AuthDecap(enc, skR, pkS) do not apply to CMS.

ASN.1 Module In order to carry a DHKEM inside a CMS KEMRecipientInfo , we define id-kem-dhkem, kema-dhkem, and DHKemParameters. EDNOTE: The other way to define this would be to call out a toplevel DHKEM for each one: id-kema-dhkem-dh id-kema-dhkem-ecdh, id-kema-dhkem-x25519, id-kema-dhkem-x448. EDNOTE: This approach adds a layer of wrapping for the benefit of agility and future-proofing. I would be happy to write them each out if that's considered better.

Security Considerations This document does not add any security considerations above those already present for the Ephemeral-Static mode of the underlying (EC)DH primitive and in .

IANA Considerations This document registers the OID id-alg-dhkem The IANA is requested to allocate a value from the "SMI Security for S/MIME Module Identifier" registry for the included ASN.1 module, and allocate values from "SMI Security for S/MIME Algorithms" to identify the new algorithm defined within.

Object Identifier Allocations

Module Registration - SMI Security for S/MIME Module Identifer

• Decimal: IANA Assigned - Replace TBDMOD
• Description: CMS-DHKEM-2023 - id-mod-cms-dhkem-2023
• References: This Document

Object Identifier Registrations - SMI Security for S/MIME Attributes

• DHKEM
  • Decimal: IANA Assigned - Replace TBDALG
  • Description: id-alg-dhkem
  • References: This Document

References Normative References This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] Vigil Security, LLC Entrust DigiCert, Inc. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Acknowledgments TODO acknowledge.