LAMPS M. Ounsworth Internet-Draft J. Gray Intended status: Standards Track Entrust Expires: 6 June 2026 J. Klaussner Bundesdruckerei GmbH 3 December 2025 Composite ML-KEM for use in Cryptographic Message Syntax (CMS) draft-ietf-lamps-cms-composite-kem-latest Abstract This document defines conventions for using Composite ML-KEM within the Cryptographic Message Syntax (CMS). This document is intended to be coupled with the CMS KEMRecipientInfo mechanism in [RFC9629]. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://lamps- wg.github.io/draft-composite-kem/draft-ietf-lamps-pq-composite- kem.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-composite-kem/. Discussion of this document takes place on the LAMPS Working Group mailing list (mailto:spams@ietf.org), which is archived at https://datatracker.ietf.org/wg/lamps/about/. Subscribe at https://www.ietf.org/mailman/listinfo/spams/. Source for this draft and an issue tracker can be found at https://github.com/lamps-wg/draft-composite-kem. 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 6 June 2026. Copyright Notice Copyright (c) 2025 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. 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 1.1. Conventions and Terminology 2. Use in CMS 2.1. Underlying Components 2.1.1. Use of the HKDF-based Key Derivation Function within CMS 2.1.2. Use of the KMAC-based Key Derivation Function within CMS 2.2. RecipientInfo Conventions 2.3. Certificate Conventions 2.4. SMIMECapabilities Attribute Conventions 3. ASN.1 Module 4. IANA Considerations 5. Security Considerations 6. References 6.1. Normative References 6.2. Informative References Appendix A. Implementation Considerations A.1. Backwards Compatibility A.2. Decapsulation Requires the Public Key Appendix B. Test Vectors Appendix C. ~~~ Appendix D. Component Algorithm Reference Appendix E. Intellectual Property Considerations Appendix F. Contributors and Acknowledgments Authors' Addresses 1. Introduction This document acts as a companion to [I-D.ietf-lamps-pq-composite-kem] by providing conventions for using the Composite ML-KEM algorithm within the Cryptographic Message Syntax (CMS). 1.1. Conventions and 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This document is consistent with all terminology from [RFC9794]. In addition, the following terms are used in this document: *ALGORITHM*: The usage of the term "algorithm" within this document generally refers to any function which has a registered Object Identifier (OID) for use within an ASN.1 AlgorithmIdentifier. This loosely, but not precisely, aligns with the definitions of "cryptographic algorithm" and "cryptographic scheme" given in [RFC9794]. *COMBINER:* A combiner specifies how multiple shared secrets are combined into a single shared secret. *DER:* Distinguished Encoding Rules as defined in [X.690]. *KEM:* A cryptographic key establishment mechanism, making no assumptions about which algorithm. *PKI:* Public Key Infrastructure, as defined in [RFC5280]. *SHARED SECRET KEY:* A value established between two communicating parties for use as cryptographic key material suitable for direct use by symmetric cryptographic algorithms. This document is concerned with shared secrets established via public key cryptographic operations. 2. Use in CMS Composite ML-KEM algorithms MAY be employed for one or more recipients in the CMS enveloped-data content type [RFC5652], the CMS authenticated-data content type [RFC5652], or the CMS authenticated- enveloped-data content type [RFC5083]. In each case, the KEMRecipientInfo [RFC9629] is used with the chosen Composite ML-KEM Algorithm to securely transfer the content-encryption key from the originator to the recipient. All recommendations for using Composite ML-KEM in CMS are fully aligned with the use of ML-KEM in CMS [I-D.ietf-lamps-cms-kyber]. 2.1. Underlying Components A compliant implementation MUST support the following algorithm combinations for the KEMRecipientInfo kdf and wrap fields when the corresponding Composite ML-KEM algorithm is listed in the KEMRecipientInfo kem field. The KDFs listed below align with the KDF used internally within the KEM combiner. An implementation MAY also support other key-derivation functions and other key-encryption algorithms within CMS KEMRecipientInfo and SHOULD use algorithms of equivalent strength or greater. +=================================+==============+=============+ | Composite ML-KEM Algorithm | KDF | Wrap | +=================================+==============+=============+ | id-MLKEM768-RSA2048-HKDF-SHA256 | id-alg-hkdf- | id- | | | with-sha256 | aes128-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM768-RSA3072-HKDF-SHA256 | id-alg-hkdf- | id- | | | with-sha256 | aes128-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM768-RSA4096-HKDF-SHA256 | id-alg-hkdf- | id- | | | with-sha256 | aes128-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM768-X25519-SHA3-256 | id-kmac256 | id- | | | | aes128-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM768-ECDH-P256-HKDF- | id-alg-hkdf- | id- | | SHA256 | with-sha256 | aes256-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM768-ECDH-P384-HKDF- | id-alg-hkdf- | id- | | SHA256 | with-sha256 | aes256-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM768-ECDH- | id-alg-hkdf- | id- | | brainpoolP256r1-HKDF-SHA256 | with-sha256 | aes256-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM1024-ECDH-P384-HKDF- | id-alg-hkdf- | id- | | SHA384 | with-sha384 | aes256-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM1024-ECDH- | id-kmac256 | id- | | brainpoolP384r1-HKDF-SHA384 | | aes256-wrap | +---------------------------------+--------------+-------------+ | id-MLKEM1024-X448-SHA3-256 | id-kmac256 | id- | | | | aes256-wrap | +---------------------------------+--------------+-------------+ Table 1: Mandatory-to-implement pairings for CMS KDF and WRAP Full specifications for the referenced algorithms can be found either further down in this section, or in Appendix D. Note that here we differ slightly from the internal KDF used within the KEM combiner in Section 6 of [I-D.ietf-lamps-pq-composite-kem] because [RFC9629] requires that the KDF listed in the KEMRecipientInfo kdf field must have an interface which accepts KDF(IKM, L, info), so here we need to use KMAC and cannot directly use SHA3. Since we require 256-bits of (2nd) pre-image resistance, we use KMAC256 for the Composite ML-KEM algorithms with internally use SHA3-256, as aligned with Table 3 of [SP.800-57pt1r5]. 2.1.1. Use of the HKDF-based Key Derivation Function within CMS Unlike within the Composite KEM Combiner function, When used as a KDF for CMS, HKDF requires use of the HKDF-Expand step so that it can accept the length parameter kekLength from CMS KEMRecipientInfo as the HKDF parameter L. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is defined in [RFC5869]. The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions. HKDF(salt, IKM, info, L) = HKDF-Expand(HKDF-Extract(salt, IKM), info, L) HKDF(salt, IKM, info, L) takes the following parameters: salt: optional salt value (a non-secret random value). In this document this parameter is left at its default value, which is the string of HashLen zeros. IKM: input keying material. In this document this is the shared secret outputted from the Encaps() or Decaps() functions. This corresponds to the IKM KDF input from Section 5 of [RFC9629]. info: optional context and application specific information. In this document this corresponds to the info KDF input from Section 5 of [RFC9629]. This is the ASN.1 DER encoding of CMSORIforKEMOtherInfo. L: length of output keying material in octets. This corresponds to the L KDF input from Section 5 of [RFC9629], which is identified in the kekLength value from KEMRecipientInfo. Implementations MUST confirm that this value is consistent with the key size of the key-encryption algorithm. HKDF may be used with different hash functions, including SHA-256 and SHA-384 [FIPS.180-4]. The object identifier id-alg-hkdf-with-sha256 and id-alg-hkdf-with-sha384 are defined in [RFC8619], and specify the use of HKDF with SHA-256 and SHA-384. The parameter field MUST be absent when this algorithm identifier is used to specify the KDF for ML-KEM in KemRecipientInfo. 2.1.2. Use of the KMAC-based Key Derivation Function within CMS KMAC256-KDF is a KMAC-based KDF specified for use in CMS in [RFC9688]. The definition of KMAC is copied here for convenience. Here, KMAC# indicates the use of either KMAC128-KDF or KMAC256-KDF, although only KMAC256 is used in this specification. KMAC#(K, X, L, S) takes the following parameters: K: the input key-derivation key. In this document this is the shared secret outputted from the Encaps() or Decaps() functions. This corresponds to the IKM KDF input from Section 5 of [RFC9629]. X: the context, corresponding to the info KDF input from Section 5 of [RFC9629]. This is the ASN.1 DER encoding of CMSORIforKEMOtherInfo. L: the output length, in bits. This corresponds to the L KDF input from Section 5 of [RFC9629], which is identified in the kekLength value from KEMRecipientInfo. The L KDF input and kekLength values are specified in octets while this L parameter is specified in bits. S: the optional customization label. In this document this parameter is unused, that is it is the zero-length string "". The object identifier for KMAC256-KDF is id-kmac256, as defined in [RFC9688]. Since the customization label to KMAC# is not used, the parameter field MUST be absent when id-kmac256 is used as part of an algorithm identifier specifying the KDF to use for Composite ML-KEM in KemRecipientInfo. 2.2. RecipientInfo Conventions When Composite ML-KEM is employed for a recipient, the RecipientInfo alternative for that recipient MUST be OtherRecipientInfo using the KEMRecipientInfo structure as defined in [RFC9629]. The fields of the KEMRecipientInfo MUST have the following values: version is the syntax version number; it MUST be 0. rid identifies the recipient's certificate or public key. kem identifies the KEM algorithm; it MUST contain one of the Composite ML-KEM identifiers listed in Section 6 of [I-D.ietf-lamps-pq-composite-kem]. kemct is the ciphertext produced for this recipient. kdf identifies the key-derivation algorithm. Note that the Key Derivation Function (KDF) used for CMS RecipientInfo process (to calculate the RecipientInfo KEK key) MAY be different than the KDF used within the Composite ML-KEM algorithm (to calculate the shared secret ss) and MAY also be different from any KDFs used internally within a component algorithm. kekLength is the size of the key-encryption key in octets. ukm is an optional random input to the key-derivation function. ML-KEM doesn't place any requirements on the ukm contents. wrap identifies a key-encryption algorithm used to encrypt the content-encryption key. encryptedKey is the result of encryptiong the CEK with the KEK. 2.3. Certificate Conventions The conventions specified in this section augment RFC 5280 [RFC5280]. The willingness to accept a Composite ML-KEM Algorithm MAY be signaled by the use of the SMIMECapabilities Attribute as specified in Section 2.5.2. of [RFC8551] or the SMIMECapabilities certificate extension as specified in [RFC4262]. The intended application for the public key MAY be indicated in the key usage certificate extension as specified in Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that conveys a Composite ML-KEM public key, then the key usage extension MUST contain only the following value: keyEncipherment The digitalSignature and dataEncipherment values MUST NOT be present. That is, a public key intended to be employed only with a Composite ML-KEM algorithm MUST NOT also be employed for data encryption or for digital signatures. This requirement does not carry any particular security consideration; only the convention that KEM keys be identified with the keyEncipherment key usage. 2.4. SMIMECapabilities Attribute Conventions Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content type [RFC5652], a compliant implementation MAY include the SMIMECapabilities attribute that announces support for the RSA-OAEP Algorithm. The SMIMECapability SEQUENCE representing a Composite ML-KEM Algorithm MUST include the appropriate object identifier as per Section 6 of [I-D.ietf-lamps-pq-composite-kem] in the capabilityID field. 3. ASN.1 Module Composite-MLKEM-CMS-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-composite-mlkem-cms-2025(TBDMOD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS SMIME-CAPS FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } kema-MLKEM768-RSA2048, kema-MLKEM768-RSA3072, kema-MLKEM768-RSA4096, kema-MLKEM768-ECDH-P384, kema-MLKEM768-ECDH-brainpoolP256r1, kema-MLKEM768-X25519, kema-MLKEM1024-ECDH-P384, kema-MLKEM1024-ECDH-brainpoolP384r1, kema-MLKEM1024-X448 FROM Composite-MLKEM-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-composite-mlkem-2025(TBDCompositeMOD) } ; -- -- Expand the S/MIME capabilities set used by CMS [RFC5911] -- -- TODO: this doesn't compile, error: -- "The referenced object in the 'ValueFromObject' -- syntax with the field '&smimeCaps' is invalid or does not exist." -- We need help from an SMIME expert SMimeCaps SMIME-CAPS ::= { kema-MLKEM768-RSA2048.&smimeCaps | kema-MLKEM768-RSA3072.&smimeCaps | kema-MLKEM768-RSA4096.&smimeCaps | kema-MLKEM768-ECDH-P384.&smimeCaps | kema-MLKEM768-ECDH-brainpoolP256r1.&smimeCaps | kema-MLKEM768-X25519.&smimeCaps | kema-MLKEM1024-ECDH-P384.&smimeCaps | kema-MLKEM1024-ECDH-brainpoolP384r1.&smimeCaps | kema-MLKEM1024-X448.&smimeCaps, ... } END 4. IANA Considerations IANA is requested to allocate a value from the "SMI Security for PKIX Module Identifier" registry [RFC7299] for the included ASN.1 module. * Decimal: IANA Assigned - *Replace TBDMOD* * Description: Composite-KEM-2025 - id-mod-composite-cms-kems * References: This Document 5. Security Considerations All security considerations from [I-D.ietf-lamps-pq-composite-kem] apply. TODO: something about choices of CMS KDFs? 6. References 6.1. Normative References [FIPS.180-4] National Institute of Standards and Technology (NIST), "FIPS Publication 180-4: Secure Hash Standard", August 2015, . [FIPS.202] National Institute of Standards and Technology (NIST), "SHA-3 Standard: Permutation-Based Hash and Extendable- Output Functions", August 2015, . [FIPS.203] National Institute of Standards and Technology (NIST), "Module-Lattice-based Key-Encapsulation Mechanism Standard", August 2024, . [FIPS.204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", August 2024, . [I-D.ietf-lamps-kyber-certificates] Turner, S., Kampanakis, P., Massimo, J., and B. Westerbaan, "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key- Encapsulation Mechanism (ML-KEM)", Work in Progress, Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22 July 2025, . [I-D.ietf-lamps-pq-composite-kem] Ounsworth, M., Gray, J., Pala, M., Klaussner, J., and S. Fluhrer, "Composite ML-KEM for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft- ietf-lamps-pq-composite-kem-11, 3 December 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, . [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10.17487/RFC8411, August 2018, . [RFC8619] Housley, R., "Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 8619, DOI 10.17487/RFC8619, June 2019, . [RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)", RFC 9629, DOI 10.17487/RFC9629, August 2024, . [RFC9688] Housley, R., "Use of the SHA3 One-Way Hash Functions in the Cryptographic Message Syntax (CMS)", RFC 9688, DOI 10.17487/RFC9688, November 2024, . [SP.800-185] National Institute of Standards and Technology (NIST), "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash", December 2016, . [SP.800-56Ar3] National Institute of Standards and Technology (NIST), "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", April 2018, . [SP.800-56Cr2] National Institute of Standards and Technology (NIST), "Recommendation for Key-Derivation Methods in Key- Establishment Schemes", August 2020, . [SP.800-57pt1r5] National Institute of Standards and Technology (NIST), "Recommendation for Key Management: Part 1 – General", May 2020, . [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2015, November 2015. 6.2. Informative References [ANSSI2024] French Cybersecurity Agency (ANSSI), Federal Office for Information Security (BSI), Netherlands National Communications Security Agency (NLNCSA), and Swedish National Communications Security Authority, Swedish Armed Forces, "Position Paper on Quantum Key Distribution", n.d., . [Aviram22] Yogev, E., "Practical (Post-Quantum) Key Combiners from One-Wayness and Applications to TLS", n.d., . [BSI2021] Federal Office for Information Security (BSI), "Quantum- safe cryptography - fundamentals, current developments and recommendations", October 2021, . [CNSA2.0] "Commercial National Security Algorithm Suite 2.0", n.d., . [ETSI.TS.103.744] ETSI, "ETSI TS 103 744 V1.1.1 CYBER; Quantum-safe Hybrid Key Exchanges", December 2020, . [FIPS-140-3-IG] National Institute of Standards and Technology (NIST), "Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program", July 2024, . [GHP18] Poettering, B., "KEM Combiners", 2018, . [I-D.ietf-lamps-cms-kyber] Prat, J., Ounsworth, M., and D. Van Geest, "Use of ML-KEM in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-cms-kyber-05, 15 October 2024, . [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-04, 11 January 2022, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, . [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, . [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, DOI 10.17487/RFC5639, March 2010, . [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, . [RFC5990] Randall, J., Kaliski, B., Brainard, J., and S. Turner, "Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 5990, DOI 10.17487/RFC5990, September 2010, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . [SP-800-227ipd] Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for Key- Encapsulation Mechanisms (Initial Public Draft)", n.d., . [SP800-131Ar2] Barker, E. and A. Roginksy, "Transitioning the Use of Cryptographic Algorithms and Key Lengths", n.d., . [X-Wing] Barbosa, M., Connolly, D., Duarte, J., Kaiser, A., Schwabe, P., Varner, K., and B. Westerbaan, "X-Wing The Hybrid KEM You’ve Been Looking For", 9 January 2024, . Appendix A. Implementation Considerations A.1. Backwards Compatibility TODO - say something meaningful about backwards compatibility within the CMS context. A.2. Decapsulation Requires the Public Key TODO - shorten this to the bit that's relevant to CMS. ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation [FIPS.203], and for this reason the private key encoding specified in FIPS 203 includes the public key. Therefore it is not required to carry it in the OneAsymmetricKey.publicKey field, which remains optional, but is strictly speaking redundant since an ML-KEM public key can be parsed from an ML-KEM private key, and thus populating the OneAsymmetricKey.publicKey field would mean that two copies of the public key data are transmitted. With regard to the traditional algorithms, RSA or Elliptic Curve, in order to achieve the public-key binding property the KEM combiner used to form the Composite ML-KEM, the combiner requires the traditional public key as input to the KDF that derives the output shared secret. Therefore it is required to carry the public key within the respective OneAsymmetricKey.publicKey as per the private key encoding given in Section 4.2 of [I-D.ietf-lamps-pq-composite-kem]. Implementers who choose to use a different private key encoding than the one specified in this document MUST consider how to provide the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoperable composite private key format given in this document in Section 4.2 of [I-D.ietf-lamps-pq-composite-kem] requires the public key of the traditional component to be included. Appendix B. Test Vectors TODO - Fix this once we have test vectors. The following test vectors are provided in a format similar to the NIST ACVP Known-Answer-Tests (KATs). The structure is that a global cacert is provided which is used to sign each KEM certificate. Within each test case there are the following values: * tcId the name of the algorithm. * ek the encapsulation public key. * x5c the X.509 certificate of the encapsulation key, signed by the cacert. * dk the decapsulation private key. * c the ciphertext. * k the derived shared secret key. Implementers should be able to perform the following tests using the test vectors below: 1. Load the public key ek or certificate x5c and perform an encapsulation for it. 2. Load the decapsulation private key dk and the ciphertext c and ensure that the same shared secret key k can be derived. Test vectors are provided for each underlying component in isolation for the purposes of debugging. Due to the length of the test vectors, you may prefer to retrieve them from GitHub. The reference implementation that generated them is also available: https://github.com/lamps-wg/draft-composite-kem/tree/main/src Appendix C. ~~~ #{::include src/testvectors_wrapped.json} #~~~ Appendix D. Component Algorithm Reference TODO: trim this down to only the ones we use in this CMS doc. This section provides references to the full specification of the algorithms used in the composite constructions. +================+========================+===================+ | Component KEM | OID | Specification | | Algorithm ID | | | +================+========================+===================+ | id-ML-KEM-768 | 2.16.840.1.101.3.4.4.2 | [FIPS.203] | +----------------+------------------------+-------------------+ | id-ML-KEM-1024 | 2.16.840.1.101.3.4.4.3 | [FIPS.203] | +----------------+------------------------+-------------------+ | id-X25519 | 1.3.101.110 | [RFC7748], | | | | [RFC8410] | +----------------+------------------------+-------------------+ | id-X448 | 1.3.101.111 | [RFC7748], | | | | [RFC8410] | +----------------+------------------------+-------------------+ | id-ecDH | 1.3.132.1.12 | [RFC5480], | | | | [RFC5915], [SEC1] | +----------------+------------------------+-------------------+ | id-RSAES-OAEP | 1.2.840.113549.1.1.7 | [RFC8017] | +----------------+------------------------+-------------------+ Table 2: Component Encryption Algorithms used in Composite Constructions +==================+=======================+===================+ | Elliptic CurveID | OID | Specification | +==================+=======================+===================+ | secp256r1 | 1.2.840.10045.3.1.7 | [RFC6090], [SEC2] | +------------------+-----------------------+-------------------+ | secp384r1 | 1.3.132.0.34 | [RFC6090], [SEC2] | +------------------+-----------------------+-------------------+ | secp521r1 | 1.3.132.0.35 | [RFC6090], [SEC2] | +------------------+-----------------------+-------------------+ | brainpoolP256r1 | 1.3.36.3.3.2.8.1.1.7 | [RFC5639] | +------------------+-----------------------+-------------------+ | brainpoolP384r1 | 1.3.36.3.3.2.8.1.1.11 | [RFC5639] | +------------------+-----------------------+-------------------+ Table 3: Elliptic Curves used in Composite Constructions +=============+========================+===============+ | HashID | OID | Specification | +=============+========================+===============+ | id-sha3-256 | 2.16.840.1.101.3.4.2.8 | [FIPS.202] | +-------------+------------------------+---------------+ Table 4: Hash algorithms used in Composite Constructions Appendix E. Intellectual Property Considerations None. Appendix F. Contributors and Acknowledgments 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), Peter C. (UK NCSC), Sophie Schmieg (Google), Deirdre Connolly (SandboxAQ), Falko Strenzke (MTG AG), Dan van Geest (Crypto Next), Piotr Popis (Enigma), and Douglas Stebila (University of Waterloo). Thanks to Giacomo Pope (github.com/GiacomoPope) whose ML-DSA and ML- KEM implementation was used to generate the test vectors. 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" - [RFC8411]. Authors' Addresses Mike Ounsworth Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: mike.ounsworth@entrust.com John Gray Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: john.gray@entrust.com Jan Klaussner Bundesdruckerei GmbH Kommandantenstr. 18 10969 Berlin Germany Email: jan.klaussner@bdr.de