Skip to content

IETF Composite ML-KEM and Composite Signatures — Alignment

This page describes how the platform's composite keys correspond to the IETF composite ML-KEM and composite ML-DSA drafts and to the JOSE profile of composite signatures. Each statement names the section it corresponds to and the component that implements it.

Documents and versions

All four documents are Internet-Drafts, work in progress; none is an RFC. Revisions were checked on the IETF datatracker on 2026-10-04.

Document Revision Primary source
draft-ietf-lamps-pq-composite-kem, Composite ML-KEM for use in X.509 Public Key Infrastructure -21 Datatracker
draft-ietf-lamps-pq-composite-sigs, Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure -19 Datatracker
draft-ietf-jose-pq-composite-sigs, PQ/T Hybrid Composite Signatures for JOSE and COSE -04 Datatracker
draft-ietf-jose-hpke-pq-pqt, JOSE HPKE PQ & PQ/T Algorithm Registrations -01 Datatracker

The LAMPS drafts define composite keys for X.509 and CMS. The platform carries its composite keys in JOSE: JWE General JSON for key encapsulation and JWS for signatures. The sections below state where the platform's constructions correspond to the drafts' and which serialization the platform uses.

Composite ML-KEM (draft-ietf-lamps-pq-composite-kem-21)

Section What the platform does
2.2 Promotion of ECDH into a KEM The same DHKEM promotion: the sender generates an ephemeral key pair, the shared secret is DH(skE, pkR) and the ciphertext is the ephemeral public key. For the NIST and Brainpool curves DH() yields Z of SP 800-56A Rev. 3 §5.7.1.2; for X25519 and X448 it yields K of RFC 7748 §6 (KemOperations, AsymmetricAlgorithmSupport)
6 Algorithm Identifiers and Parameters The catalogue carries the component pairs of eight of the draft's twelve composites (listed below)
9.1 Why Hybrids? The same rationale: the derived key stays secret while at least one component is unbroken
9.2 KEM Combiner; Appendix E.2 ETSI CatKDF Appendix E.2 describes ETSI CatKDF as the more conservative choice, binding the public keys and ciphertexts of both components. Every platform KDF token binds both ciphertexts, both public keys and a domain separator naming the pairing (KeyCombinerRegistry, CombinerInput)
10.3 Profiling down the number of options The three composites §10.3 recommends are available as pairings: X25519 + ML-KEM-768, P-256 + ML-KEM-768 and P-384 + ML-KEM-1024
10.4 Decapsulation Requires the Public Key Both component public keys are held with the key material and enter the combiner on encapsulation and on decapsulation (CompositeJweCoreDecryptor)

The eight composites of §6 whose component pairs the catalogue carries:

Draft composite Catalogue pairing
id-MLKEM768-X25519-SHA3-256 X25519 + ML-KEM-768
id-MLKEM768-ECDH-P256-SHA3-256 P-256 + ML-KEM-768
id-MLKEM768-ECDH-P384-SHA3-256 P-384 + ML-KEM-768
id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 brainpoolP256r1 + ML-KEM-768
id-MLKEM1024-ECDH-P384-SHA3-256 P-384 + ML-KEM-1024
id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 brainpoolP384r1 + ML-KEM-1024
id-MLKEM1024-X448-SHA3-256 X448 + ML-KEM-1024
id-MLKEM1024-ECDH-P521-SHA3-256 P-521 + ML-KEM-1024

The content-encryption key is derived by the platform's own combiners — HKDF-SHA256 (default), HKDF-SHA384, HKDF-SHA512, and ETSI TS 103 744 CatKDF and CasKDF — and the result is serialized as JWE General JSON. The combiners are described on ETSI TS 103 744 Alignment.

Composite signatures (draft-ietf-lamps-pq-composite-sigs-19, draft-ietf-jose-pq-composite-sigs-04)

Document and section What the platform does
lamps-pq-composite-sigs-19 §2.2 Prefix, Label, and CTX; §3.2 Sign One composite signature value mldsaSig ‖ tradSig over the message representative M' = Prefix ‖ Label ‖ 0x00 ‖ PH(M), with the empty application context the JOSE profile fixes. The ML-DSA component is signed with the Label as its context (CompositeSignatureConstruction)
lamps-pq-composite-sigs-19 §3.3 Verify The signature is valid only when both component signatures verify (CompositeJwsCoreVerifier)
lamps-pq-composite-sigs-19 §6 Algorithm Identifiers and Parameters Ten of the fourteen signature pairings carry the draft's §6 Label: MLDSA44-Ed25519, MLDSA65-Ed25519, MLDSA87-Ed448, MLDSA44-ECDSA-P256, MLDSA65-ECDSA-P256, MLDSA65-ECDSA-P384, MLDSA87-ECDSA-P384, MLDSA87-ECDSA-P521, MLDSA65-ECDSA-brainpoolP256r1 and MLDSA87-ECDSA-brainpoolP384r1. The other four carry platform Labels (ANKATECH-COMPSIG-…) (CompositeSignatureParameters in common-algorithms)
jose-pq-composite-sigs-04 §4.2 Composite Sign, §4.3 Composite Verify M is the JWS Signing Input of RFC 7515 §5.1, so the protected header is signed. Detached payloads follow RFC 7797, with b64: false and crit: ["b64"] (CompositeJwsCoreSigner)
jose-pq-composite-sigs-04 §5.1 JOSE algorithms Six pairings use the draft's JOSE alg names: ML-DSA-44-ES256, ML-DSA-65-ES256, ML-DSA-87-ES384, ML-DSA-44-Ed25519, ML-DSA-65-Ed25519 and ML-DSA-87-Ed448

The attached JWS is a compact JWS, presented at the API as a General JSON serialization with one signature; the detached form is the flattened {"protected", "signature"} object.

Serialization facts

  • Composite KEM: JWE General JSON (RFC 7516 §7.2.1) with one recipient per component. Each recipient header carries alg only, naming its component, and encrypted_key holds that component's encapsulation — the ephemeral public key for the classical component, the KEM ciphertext for the post-quantum one. The KDF token travels as anka_kdf in the integrity-protected header (CompositeJweCoreEncryptor).
  • Component public keys are exported as X.509 SubjectPublicKeyInfo, one per component (KeyExportResponse).
  • SIMPLE EC keys use RFC 7518 §4.6 ECDH-ES+A256KW (JweCoreEncryptor); composite components use the ECDH-KEM above.

References