]> 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

Security LAMPS Internet-Draft The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptalanysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structure CompositeCiphertextValue which is a sequence of the respective ciphertexts for each component algorithm. Explicit pairings of algorithms are defined which should meet most Internet needs. For the purpose of combining KEMs, the combiner function from is used. This document is intended to be coupled with the composite keys structure define in and the CMS KEMRecipientInfo mechanism in .

Changes in version -02

• Removed all references to generic composite.
• Added selection criteria note about requesting new explicit combinations.

Introduction During the transition to post-quantum cryptography, there will be uncertainty as to the strength of cryptographic algorithms; we will no longer fully trust traditional cryptography such as RSA, Diffie-Hellman, DSA and their elliptic curve variants, while we may also not fully trust their post-quantum replacements until they have had sufficient scrutiny and time to discover and fix implementation bugs. Unlike previous cryptographic algorithm migrations, the choice of when to migrate and which algorithms to migrate to, is not so clear. Even after the migration period, it may be advantageous for an entity's cryptographic identity to be composed of multiple public-key algorithms. The deployment of composite public keys and composite encryption using post-quantum algorithms will face two challenges

• Algorithm strength uncertainty: During the transition period, some post-quantum signature and encryption algorithms will not be fully trusted, while also the trust in legacy public key algorithms will start to erode. A relying party may learn some time after deployment that a public key algorithm has become untrustworthy, but in the interim, they may not know which algorithm an adversary has compromised.
• Migration: During the transition period, systems will require mechanisms that allow for staged migrations from fully classical to fully post-quantum-aware cryptography.

This document provides a mechanism to address algorithm strength uncertainty by building on by providing the format and process for combining multiple cryptographic algorithms into a single key encapsulation operation. Backwards compatibility is not directly covered in this document, but is the subject of . This document is intended for general applicability anywhere that key establishment or enveloped content encryption is used within PKIX or CMS structures.

Algorithm Selection Criteria The composite algorithm combinations defined in this document were chosen according to the following guidelines:

1. A single RSA combination is provided (but RSA modulus size not mandated), matched with NIST PQC Level 3 algorithms.
2. Elliptic curve algorithms are provided with combinations on each of the NIST , Brainpool , and Edwards curves. NIST PQC Levels 1 - 3 algorithms are matched with 256-bit curves, while NIST levels 4 - 5 are matched with 384-bit elliptic curves. This provides a balance between matching classical security levels of post-quantum and traditional algorithms, and also selecting elliptic curves which already have wide adoption.
3. NIST level 1 candidates (Falcon512 and Kyber512) are provided, matched with 256-bit elliptic curves, intended for constrained use cases. The authors wish to note that although all the composite structures defined in this and the companion documents and pecifications are defined in such a way as to easily allow 3 or more component algorithms, it was decided to only specify explicit pairs. This also does not preclude future specification of explicit combinations with three or more components.

To maximize interoperability, use of the specific algorithm combinations specified in this document is encouraged. If other combinations are needed, a separate specification should be submitted to the IETF LAMPS working group. To ease implementation, these specifications are encouraged to follow the construction pattern of the algorithms specified in this document.

Terminology 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 document is consistent with all terminology from . In addition, the following terms are used in this document: BER: Basic Encoding Rules (BER) as defined in . CLIENT: Any software that is making use of a cryptographic key. This includes a signer, verifier, encrypter, decrypter. COMBINER: A combiner specifies how multiple shared secrets are combined into a single shared secret. DER: Distinguished Encoding Rules as defined in . KEM: A key encapsulation mechanism as defined in . PKI: Public Key Infrastructure, as defined in . SHARED SECRET: A value established between two communicating parties for use as cryptographic key material, but which cannot be learned by an active or passive adversary. This document is concerned with shared secrets established via public key cryptagraphic operations.

Composite KEM Structures

Key Encapsulation Mechanisms (KEMs) We borrow here the definition of a key encapsulation mechanism (KEM) from , in which a KEM is a cryptographic primitive that consists of three algorithms:

• KeyGen() -> (pk, sk): A probabilistic key generation algorithm, which generates a public key pk and a secret key sk.
• Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public key pk and outputs a ciphertext ct and shared secret ss.
• Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret key sk and ciphertext ct and outputs a shared secret ss, or in some cases a distinguished error value.

This document is not concerned with the KeyGen() algorithm of a KEM, but it is included above for completeness. The KEM interface defined above differs from both traditional key transport mechanism (for example for use with KeyTransRecipientInfo defined in ), and key agreement (for example for use with KeyAgreeRecipientInfo defined in ). The KEM interface was chosen as the interface for a composite key exchange because it allows for arbitrary combinations of component algorithm types since both key transport and key agreement mechanisms can be promoted into KEMs in the following ways: A key transport mechanism can be transformed into a KEM.Encaps(pk) by generating a random shared secret ss and performing KeyTrans.Encrypt(pk, ss) -> ct; and into a KEM.Decaps(sk, ct) by KeyTrans.Decrypt(sk, ct) -> ss. This follows the pattern of RSA-KEM . A key agreement mechanism can be transformed into a KEM.Encaps(pk) by generating an ephemeral key pair (pk_e, sk_e), and performing KeyAgree(pk, sk_e) -> (ss, pk_e); and into a KEM.Decaps(sk, ct) by completing the key agreement as KeyAgree(pk_e, sk) -> ss. A composite KEM allows two or more underlying key transport, key agreement, or KEM algorithms to be combined into a single cryptographic operations by performing each operation, transformed to a KEM as outline above, and using a specified combiner function to combine the two or more component shared secrets into a single shared secret. The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated. By using the KEM combiner defined in , the composite KEMs defined in this document inherit the IND-CCA2 security from the general combiner. TODO: needs more formal analysis that the methods of transforming KeyTrans and KeyAgree meet this.

kema-CompositeKEM The ASN.1 algorithm object for a composite KEM is: The following is an explanation how KEM-ALGORITHM elements are used to create Composite KEMs:

SIGNATURE-ALGORITHM element	Definition
IDENTIFIER	The Object ID used to identify the composite Signature Algorithm
VALUE	The Sequence of BIT STRINGS for each component signature value
PARAMS	Parameters of type CompositeKemParams may be provided when required
PUBLIC-KEYS	The composite key required to produce the composite signature
SMIME_CAPS	Not needed for composite

Composite Keys A composite KEM MAY be associated with a composite public key as defined in [I-D.ounsworth-pq-composite-keys], but MAY also be associated with multiple public keys from different sources, for example multiple X.509 certificates, or multiple cryptographic modules. In the latter case, composite KEMs MAY be used as the mechanism for carrying multiple ciphertexts in a non-composite hybrid encryption equivalent of those described for digital signatures in [I-D.becker-guthrie-noncomposite-hybrid-auth].

Key Usage Bits When using composite KEM keys in a structure which defines a key usage (such as in an X509Certificate as defined in ), the following key usage MUST be used. Additional key usages SHOULD not be used.

CompositeCiphertextValue The compositeCipherTextValue is a concatenation of the ciphertexts of the underlying component algorithms. It is represented in ASN.1 as follows:

CompositKemParameters Composite KEM parameters are defined as follows and MAY be included when a composite KEM algorithm is used with an AlgorithmIdentifier: The KEM's CompositeKemParams sequence MUST contain the same component algorithms listed in the same order as in the associated CompositePublicKey. For explicit composite algorithms, it is required in cases where one or both of the components themselves have parameters that need to be carried, however the authors have chosen to always carry it in order to simplify parsers. Implementation SHOULD NOT rely directly on the algorithmIDs contained in the CompositeKemParams and SHOULD verify that they match the algorithms expected from the overall composite AlgorithmIdentifier.

Encoding Rules Many protocol specifications will require that composite KEM data structures be represented by an octet string or bit string. When an octet string is required, the DER encoding of the composite data structure SHALL be used directly. EDNOTE: will this definition include an ASN.1 tag and length byte inside the OCTET STRING object? If so, that's probably an extra unnecessary layer. When a bit string is required, the octets of the DER encoded composite data structure SHALL be used as the bits of the bit string, with the most significant bit of the first octet becoming the first bit, and so on, ending with the least significant bit of the last octet becoming the last bit of the bit string. In the interests of simplicity and avoiding compatibility issues, implementations that parse these structures MAY accept both BER and DER.

KEM Combiner TODO: as per https://www.enisa.europa.eu/publications/post-quantum-cryptography-integration-study section 4.2, might need to specify behaviour in light of KEMs with a non-zero failure probility. This document follows the construction of , which is repeated here for clarity: where:

• KDF and H, and outputBits represent a hash functions suitable to the chosen KEMs,
• fixedInfo any additional context string provided by the protocol,
• counter is fixed to the 32-bit value 0x00000001,
• || represents concatenation.

Each registered composite KEM algorithm must specify the exact KEM combiner construction that is to be used. For convenience we define the following KMAC-basid intantiations of KEM combiner: KEM Combiners

KEM Combiner	KDF	H	outputBits
KMAC128/256	KMAC128	SHA3-256	256
KMAC256/384	KMAC256	SHA3-512	384
KMAC256/512	KMAC256	SHA3-512	512

KMAC is defined in NIST SP 800-185 . The KMAC(K, X, L, S) parameters are instantiated as follows:

• K: the ASCI value of the name of the Kem Type OID.
• X: the value "0x00000001 || k_1 || ... || k_n || fixedInfo", where k_i = H(ss_i || ct_i), as defined above.
• L: integer representation of outputBits.
• S: empty string.

~~~ BEGIN EDNOTE ~~~ these choices are somewhat arbitrary but aiming to match security level of the input KEMs. Feedback welcome.

• Kyber512: KMAC128/256
• Kyber768: KMAC256/384
• Kyber1024 KMAC256/512

~~~ END EDNOTE ~~~ For example, the KEM combiner instantiation of the first entry of would be:

Algorithm Identifiers This table summarizes the list of explicit composite Signature algorithms by the key and signature OID and the two component algorithms which make up the explicit composite algorithm. These are denoted by First Signature Alg, and Second Signature Alg. The OID referenced are TBD and MUST be used only for prototyping and replaced with the final IANA-assigned OIDS. The following prefix is used for each: replace <CompKEM> with the String "2.16.840.1.114027.80.5.2" Therefore <CompKEM>.1 is equal to 2.16.840.1.114027.80.5.2.1 The "KEM Combiner" column refers to the definitions in . Composite KEM key types

KEM Type OID	OID	First Algorithm	Second Algorithm	KEM Combiner
id-Kyber512-ECDH-P256-KMAC128	<CompKEM>.1	Kyber512	ECDH-P256	KMAC128/256
id-Kyber512-ECDH-brainpoolP256r1-KMAC128	<CompKEM>.2	Kyber512	ECDH-brainpoolp256r1	KMAC128/256
id-Kyber512-X25519-KMAC128	<CompKEM>.3	Kyber512	X25519	KMAC128/256
id-Kyber768-RSA-KMAC256	<CompKEM>.4	Kyber768	RSA-KEM	KMAC256/384
id-Kyber768-ECDH-P256-KMAC256	<CompKEM>.5	Kyber768	ECDH-P256	KMAC256/384
id-Kyber768-ECDH-brainpoolP256r1-KMAC256	<CompKEM>.6	Kyber768	ECDH-brainpoolp256r1	KMAC256/384
id-Kyber768-X25519-KMAC256	<CompKEM>.7	Kyber768	X25519	KMAC256/384
id-Kyber1024-ECDH-P384-KMAC256	<CompKEM>.8	Kyber1024	ECDH-P384	KMAC256/512
id-Kyber1024-ECDH-brainpoolP384r1-KMAC256	<CompKEM>.9	Kyber1024	ECDH-brainpoolP384r1	KMAC256/512
id-Kyber1024-X448-KMAC256	<CompKEM>.10	Kyber1024	X448	KMAC256/512

The table above contains everything needed to implement the listed explicit composite algorithms, with the exception of some special notes found below in this section. See the ASN.1 module in section for the explicit definitions of the above Composite signature algorithms. Full specifications for the referenced algorithms can be found as follows:

• ECDH: There does not appear to be a single IETF definition of ECDH, so we refer to the following:
  • ECDH NIST: SHALL be Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) as defined in section 5.7.1.2 of .
  • ECDH BSI / brainpool: SHALL be Elliptic Curve Key Agreement algorithm (ECKA) as defined in section 4.3.1 of
• Kyber:
• RSA-KEM:
• X25519 / X448:

EDNOTE: I believe that and give equivalent and interoperable algorithms, so maybe this is extranuous detail to include?

Notes on id-Kyber768-RSA-KMAC256 Use of RSA-KEM deserves a special explanation. GenericHybridParameters is defined in , repeated here for clarity: The GenericHybridParameters.kem MUST be id-kem-rsa as defined in : The associated parameters for id-kem-rsa have type RsaKemParameters: For use with id-Kyber768-RSA-KMAC256, the keyDerivationFunction SHALL be id-sha3-384 and keyLength SHALL be 384. EDNOTE: I'm borrowing id-sha3-384 from draft-turner-lamps-adding-sha3-to-pkix-00, which looks ilke was abandoned. Do we have PKIX OIDs for SHA3? EDNOTE: Since the crypto is fixed, we could omit the parameters entirely and expect implementations to re-constitute the params structures as necessary in order to call into lower-level crypto libraries. TODO: there must be a way to put all this the ASN.1 Module rather than just specifying it as text?

ASN.1 Module !!Composite-KEM-2023.asn ]]>

IANA Considerations The following need to be assigned by IANA:

• The OID for the ASN.1 module Composite-KEM-2023

TODO

Security Considerations

Policy for Deprecated and Acceptable Algorithms Traditionally, a public key, certificate, or signature contains a single cryptographic algorithm. If and when an algorithm becomes deprecated (for example, RSA-512, or SHA1), it is obvious that structures using that algorithm are implicitly revoked. In the composite model this is less obvious since implementers may decide that certain cryptographic algorithms have complementary security properties and are acceptable in combination even though one or both algorithms are deprecated for individual use. As such, a single composite public key, certificate, signature, or ciphertext may contain a mixture of deprecated and non-deprecated algorithms. Specifying behaviour in these cases is beyond the scope of this document, but should be considered by Implementers and potentially in additional standards. EDNOTE: Max is working on a CRL mechanism to accomplish this.

OR Modes TODO -- we'll need security consideration analysis of whatever OR modes we choose.

KEM Combiner This document uses directly the KEM Combiner defined in and therefore inherits all of its security considerations, which the authors believe have all been addressed in the concrete choices for explicit composites.

References Normative References 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. 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 specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [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] 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 provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. 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. This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. Entrust Limited Entrust Limited CableLabs D-Trust GmbH The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptalanysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structures CompositePublicKey and CompositePrivateKey, which are sequences of the respective structure for each component algorithm. Explicit pairings of algorithms are defined which should meet most Internet needs. The generic composite key type is also defined which allows arbitrary combinations of key types to be placed in the CompositePublicKey and CompositePrivateKey structures without needing the combination to be pre-registered or pre-agreed. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite signatures and encryption, such as [I-D.ounsworth-pq-composite-sigs] and [I-D.ounsworth-pq-composite-kem]. 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 CMS content. sn3rd AWS AWS Cloudflare This document specifies algorithm identifiers and ASN.1 encoding format for the United States National Institute of Standards and Technology's Post Quantum Cryptography Key Encapsulation Mechanism algorithms. The algorithms covered are Kyber TBD1. The encoding for public key and private key is also provided. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. After NIST has standardized its first algorithms, this document will replace TBD, with the appropriate algorithms and parameters before proceeding to ratification. The algorithm Kyber TBD1 has been added as an example in this draft, to provide a more detailed illustration of the content - it by no means indicates its inclusion in the final version. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) ITU-T Federal Office for Information Security (BSI) National Institute of Standards and Technology (NIST) Informative References This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes. This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Entrust Limited Entrust Limited CableLabs The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptanalysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structures CompositeSignatureValue, and CompositeSignatureParams, which are sequences of the respective structure for each component algorithm. The explicit variant is defined which allows for a set of signature algorithm identifier OIDs to be registered together as an explicit composite signature algorithm and assigned an OID. The generic composite variant is also defined which allows arbitrary combinations of signature algorithms to be used in the CompositeSignatureValue and CompositeSignatureParams structures without needing the combination to be pre-registered or pre-agreed. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite public and private keys and encryption [I-D.ounsworth-pq-composite-keys], however may also be used with non-composite keys, such as when a protocol combines multiple certificates into a single cryptographic operation. University of Waterloo Cisco Systems University of Haifa and Amazon Web Services Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. UK National Cyber Security Centre One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to ensure consistency and clarity across different protocols, standards, and organisations. Entrust Limited Proton AG BSI The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret. This document defines a comprehensible and easy to implement Keccak- based KEM combiner to join an arbitrary number of key shares, that is compatible with NIST SP 800-56Cr2 [SP800-56C] when viewed as a key derivation function. The combiners defined here are practical multi- PRFs and are CCA-secure as long as at least one of the ingredient KEMs is.

Samples TBD

Implementation Considerations This section addresses practical issues of how this draft affects other protocols and standards. EDNOTE 10: Possible topics to address:

• The size of these certs and cert chains.
• In particular, implications for (large) composite keys / signatures / certs on the handshake stages of TLS and IKEv2.
• If a cert in the chain is a composite cert then does the whole chain need to be of composite Certs?
• We could also explain that the root CA cert does not have to be of the same algorithms. The root cert SHOULD NOT be transferred in the authentication exchange to save transport overhead and thus it can be different than the intermediate and leaf certs.
• We could talk about overhead (size and processing).
• We could also discuss backwards compatibility.
• We could include a subsection about implementation considerations.

Backwards Compatibility As noted in the introduction, the post-quantum cryptographic migration will face challenges in both ensuring cryptographic strength against adversaries of unknown capabilities, as well as providing ease of migration. The composite mechanisms defined in this document primarily address cryptographic strength, however this section contains notes on how backwards compatibility may be obtained. The term "ease of migration" is used here to mean that existing systems can be gracefully transitioned to the new technology without requiring large service disruptions or expensive upgrades. The term "backwards compatibility" is used here to mean something more specific; that existing systems as they are deployed today can interoperate with the upgraded systems of the future. These migration and interoperability concerns need to be thought about in the context of various types of protocols that make use of X.509 and PKIX with relation to key establishment and content encryption, from online negotiated protocols such as TLS 1.3 and IKEv2 , to non-negotiated asynchronous protocols such as S/MIME signed email , as well as myriad other standardized and proprietary protocols and applications that leverage CMS encrypted structures.

K-of-N modes ~~~ BEGIN EDNOTE ~~~ In the context of encryption, K-of-N modes could mean one of two things: Type 1: sender uses a subset This would mean the sender (encrypter) uses a subset of K the N component keys within the receiver's public key. The obvious way to combine them is with skipping the unused keys / algorithms and emitting a NULL ciphertext in their place. This mechanism is straight-forward and allows ease of migration where a sender encounters a composite encryption public key where it does not support all component algorithms. It also supports performance optimization where, for example, a receiver can be issued a key with many component keys and a sender can choose the highest-performance subset that are still considered safe. Type 2: receiver uses a subset This would mean that the sender (encrypter) uses all N of the component keys within the receiver's public key in such a way that the receiver (decrypter) only needs to use K private keys to decrypt the message. This implies the need for some kind of Shamir's-like secret splitting scheme. This is a reasonably complex mechanism and it's currently unclear if there are any use-cases that require such a mechanism. ~~~ END EDNOTE ~~~

Parallel PKIs We present the term "Parallel PKI" to refer to the setup where a PKI end entity possesses two or more distinct public keys or certificates for the same identity (name), but containing keys for different cryptographic algorithms. One could imagine a set of parallel PKIs where an existing PKI using legacy algorithms (RSA, ECC) is left operational during the post-quantum migration but is shadowed by one or more parallel PKIs using pure post quantum algorithms or composite algorithms (legacy and post-quantum). Equipped with a set of parallel public keys in this way, a client would have the flexibility to choose which public key(s) or certificate(s) to use in a given signature operation. For negotiated protocols, the client could choose which public key(s) or certificate(s) to use based on the negotiated algorithms. For non-negotiated protocols, the details for obtaining backwards compatibility will vary by protocol, but for example in CMS . EDNOTE: I copied and pruned this text from . It probably needs to be fleshed out more as we better understand the implementation concerns around composite encryption.

Intellectual Property Considerations The following IPR Disclosure relates to this draft: https://datatracker.ietf.org/ipr/3588/ EDNOTE: I don't think this applies to this draft.

Contributors and Acknowledgements This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past year in pursuit of this document: Serge Mister (Entrust), Ali Noman (Entrust), Scott Fluhrer (Cisco), Jan Klaussner (D-Trust), Max Pala (CableLabs), and Douglas Stebila (University of Waterloo). We are grateful to all, including any contributors who may have been inadvertently omitted from this list. This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - .

Making contributions Additional contributions to this draft are welcome. Please see the working copy of this draft at, as well as open issues at: https://github.com/EntrustCorporation/draft-composite-kem/