Editorial comments from Piotr

[ounsworth]

https://mailarchive.ietf.org/arch/msg/spasm/khasPf3y0_-Lq_0NtJe92unUw6o/

2. Notes on the document "Composite KEM" version 4 (order of appearance) a) Section 2.3.1

   (…) it produces a composite public key pk as per Section 3.2 and a composite secret key sk is per Section 3.3. it produces a composite public key pk as per Section 3.2 and a composite secret key sk as per Section 3.3.

b) Section 2.3.2

DHKEM.Encaps(pkR): RSA-OAEP.Encaps(pkR):

DHKEM.Decap(skR, enc): RSA-OAEP.Decap(skR, enc):

c) Section 3.1

pk-MLKEM512-ECDH-P256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM512-ECDH-P256, OCTET STRING, ECPoint } pk-MLKEM512-ECDH-P256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM512-ECDH-P256, BIT STRING, ECPoint }

d) Section 3.2

A composite key MUST contain two component public keys. The order of the component keys is determined by the definition of the corresponding algorithm identifier as defined in section Section 5. A composite key MUST contain two component public keys as SEQUENCE of two bit strings. The order of the component keys is determined by the definition of the corresponding algorithm identifier as defined in Section 5.

e) Section 3.3

CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey

Each element is a OneAsymmetricKey` [RFC5958] object for a component private key.

The parameters field MUST be absent.

The order of the component keys is the same as the order defined in Section 3.2 for the components of CompositeKEMPublicKey.

When a CompositePrivateKey is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to Section 5, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MAY be present in the CompositeKEMPrivateKey.

CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING

Each element is a OneAsymmetricKey` [RFC5958] object for a component private key (privateKey field).

The order of the component keys is the same as the order defined in Section 3.2 for the components of CompositeKEMPublicKey.

When a CompositeKEMPrivateKey is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to Section 5 (the parameters field MUST be absent), the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MAY be present in the OneAsymmetricKey structure containing CompositeKEMPrivateKey and in that case version is 2.

f) Section 4.2

4.2. CompositeCiphertextValue

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

4.2. CompositeCipherTextValue

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

g) Section 4.3

KEK <- Combiner(tradSS, mlkemSS, tradCT, tradPK, domSep) = KDF(counter || tradSS || mlkemSS || tradCT || tradPK || domSep, outputBits)

           Figure 1: Generic KEM combiner construction

where:

• KDF(message, outputBits) represents a hash function suitable to the chosen KEMs according to {tab-kem-combiners}.

• counter SHALL be the fixed 32-bit value 0x00000001 which is placed here solely for the purposes of compliance with [SP.800-56Cr2].

• tradSS is the shared secret from the traditional component (elliptic curve or RSA).

• mlkemSS is the shared secret from the ML-KEM componont.

• tradCT is the ciphertext from the traditional component (elliptic curve or RSA).

• tradPK is the public key of the traditional component (elliptic curve or RSA).

• domSep SHALL be the DER encoded value of the object identifier of the composite KEM algorithm as listed in Section 5.1.

• || represents concatenation.

Each registered composite KEM algorithm must specify the choice of KDF, demSep, and outputBits to be used. KEK <- Combiner(tradSS, mlkemSS, tradCT, tradPK, domSep) =

SHA3(counter || tradSS || mlkemSS || tradCT || tradPK || domSep) ([SP.800-56Cr2] Section 4.1 Option 1 (when KDF is SHA3))

            Figure 1: Generic KEM combiner construction

where:

• counter SHALL be the fixed 32-bit value 0x00000001 which is placed here solely for the purposes of compliance with [SP.800-56Cr2].

• tradSS is the shared secret from the traditional component (ECDH or RSA).

• mlkemSS is the shared secret from the ML-KEM component.

• tradCT is the ciphertext from the traditional component (ECDH or RSA). Note: In the case of ECDH, this is the sender's ephemeral public key.

• tradPK is the recipient's public key of the traditional component (ECDH or RSA).

• domSep SHALL be the DER encoded value of the object identifier of the composite KEM algorithm as listed in Section 5.1.

• || represents concatenation.

  Each registered composite KEM algorithm (see {tab-kem-combiners}) must specify the choice of KDF (ie. type of SHA3 function) and domSep to be used. Comment:

  1. The use of the counter parameter is probably redundant - see Falko Strenzke email from 2024/07/24
  2. Removing outputBits is related to replacing KMAC with SHA3.

h) Section 4.4

This construction is specifically designed to conform with Section 4.1 Option 1 (when KDF is SHA3) or Option 3 (when KDF is KMAC) in the following way:

In both cases we match exactly the construction using the allowed "hybrid" shared secret of the form Z' = Z || T to yield the construction This construction is specifically designed to conform with [SP.800- 56Cr2] Section 4.1 Option 1 (when KDF is SHA3). In any cases we match exactly the construction using the allowed "hybrid" shared secret of the form Z' = Z || T (see Section 2 of the [SP.800-56Cr2]) to yield the construction:

(…) The last sentence starting with: “In the case that KDF is KMAC,…” should be removed.

---

Piotr Popis

[ounsworth]

More editorial feedback here:

https://mailarchive.ietf.org/arch/msg/spasm/khasPf3y0_-Lq_0NtJe92unUw6o/

[ounsworth]

Hi Piotr,

Thank you so much for this detailed review. I have incorporated most of your feedback in .

The one that I didn't understand is your comment "e) Section 3.3". You are suggesting changing

OLD """ CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey

Each element is a OneAsymmetricKey` [RFC5958] object for a component private key. """

NEW """ CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING

Each element is a OneAsymmetricKey` [RFC5958] object for a component private key (privateKey field). """

I suppose that basically means SEQUENCE OF OCTET STRING{ DER{ OneAsymmetricKey } }

Can you explain the advantage of this vs just encoding the OneAsymetricKey directly? Or have I misunderstood your suggestion?

You made a suggestion that the "Use in CMS" section should specify a mandatory-to-implement subset of the larger table of composite algorithms:

""" 6.1. Underlying Components

A CMS implementation that supports a composite KEM algorithm MUST

support at least the following underlying components:

id-MLKEM512-ECDH-P256

id-MLKEM512-RSA (RSA 2048 and RSA 3072)

id-MLKEM1024-ECDH-P521 """

Unless the WG feels strongly, I am going to leave out any concept of "mandatory-to-implement" from this draft. X.509 and CMS are used in such broad and diverse applications and jurisdictions that I don't think we are in a position to make policy recommendations.

[PiotrPopis]

Section 3.3 In your proposal there is: CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey

According to RFC 5958: OneAsymmetricKey ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] Attributes OPTIONAL, ..., [[2: publicKey [1] PublicKey OPTIONAL ]], ... } PrivateKey ::= OCTET STRING

I believe that to specify a pair of composite private keys, a single sequence of OneAsymmetricKey is sufficient, in which the privateKey field will be a sequence of two OCTET STRING, each of which contains the private key of the appropriate algorithm (order by OID). Ie.: CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING PrivateKey ::= CompositeKEMPrivateKey

One OneAsymmetricKey sequence (instead of two) allows the use of a composite OID pointer to the algorithm identifier (it is not clear to me whether in your proposal of two OneAsymmetricKey sequences there would be a repeated composite OID as stated the text into Section 3,3?; or rather separate OIDs pointing to individual algorithms?).

Furthermore, there is an incomprehensible note in your proposal: When a Composite(KEM?)PrivateKey is conveyed inside a OneAsymmetricKey structure (...) the privateKey field SHALL contain the CompositeKEMPrivateKey... Considering that CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey this means that PrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey, and yet the privateKey field is inside the OneAsymmetricKey sequence.

After my corrections the relevant text is rather understandable: When a CompositeKEMPrivateKey is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to Section 5 (the parameters field MUST be absent), the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MAY be present in the OneAsymmetricKey structure containing CompositeKEMPrivateKey and in that case version is 2.