Editorial changes and some proposals (mainly clarifying) to version 5.

[PiotrPopis]

Editorial changes

1. Section 3

• KDF(message) represents a key derivation function suitable to the
  chosen KEMs according to {tab-kem-combiners}. All KDFs (…)

• KDF(message) represents a key derivation function suitable to the
  chosen KEMs according to Table 2. All KDFs (…)

2. Section 3.3

Each registered Composite ML-KEM algorithm specifies the choice of
KDF andDomain to be used in Section 7 and Section 7.2 below.

Each registered Composite ML-KEM algorithm specifies the choice of
KDF and Domain to be used in Section 7 and Section 7.2 below.

3. Section 4.1

1. Generate componint keys.

1. Generate component keys.

2. Section 4.2

Composite public key conisting of encryption public keys for each component.

Composite public key consisting of encryption public keys for each component.

5. Section 4.2

Trad A placeholder for the specific ML-KEM algorithm and
parameter set to use, for example "RSA-OAEP"
or "X25519".

Trad A placeholder for the specific traditional algorithm and
parameter set to use, for example "RSA-OAEP"
or "X25519".

6. Section 5

For timing-invariance reasons, it is RECOMMENDED to perform both decapsulation operations and check for errors afterwards to to prevent an attacker from using a timing channel to tell which component failed decapsulation.

For timing-invariance reasons, it is RECOMMENDED to perform both decapsulation operations and check for errors afterwards to prevent an attacker from using a timing channel to tell which component failed decapsulation.

7. Section 5

ie

i.e.
Note: also Section 7.1, 7.3 (2 times) and 11.3.

8. Section 5.1

For use with this document, ML-KEM keys MUST be be the raw BIT STRING (…)

For use with this document, ML-KEM keys MUST be the raw BIT STRING (…).

9. Section 5.2

For more details on the security considerations around key reuse, see section Section 11.2.

For more details on the security considerations around key reuse, see Section 11.2

10. Section 7.2

The KEM combiner defined in section Section 3.3 requires a domain
separator Domain input.

The KEM combiner defined in Section 3.3 requires a domain
separator Domain input.

11. Section 7.3

(…) however SHA2 is not us must be wrapped in the HKDF construction.

(…) however SHA2 is not so must be wrapped in the HKDF construction.

12. Section 7.4

The RSA component keys MUST be generated at the 2048-bit and 3072-bit
security levels respectively.

The RSA component keys MUST be generated at the 2048-bit, 3072-bit and 4096-bit security levels respectively.

13. Section 8.1.1

IKM: input keying material. In this document this is the shared
secret outputted from the Encapsulate() or Decapsulate() functions.

IKM: input keying material. In this document this is the shared
secret outputted from the Encaps() or Decaps() functions.

Rationale: Consistency with other parts of the standard, e.g. Section 3.

14. Section 8.1.2

K: the input key-derivation key. In this document this is the
shared secret outputted from the Encapsulate() or Decapsulate()
functions.

K: the input key-derivation key. In this document this is the
shared secret outputted from the Encaps() or Decaps()
functions.

15. Section 8.2

wrap identifies a key-encryption algorithm used to encrypt the
content-encryption key.

wrap identifies a key-encryption algorithm used to encrypt the
content-encryption key.

encryptedKey is the result of encrypting the CEK with the KEK.

Rationale: To be consistent with RFC 9629 a description of the encryptedKey field should be added.

16. Section 11.1.1

(…) and therefore secure so, long as one of the component KEMs is.

(…) and therefore secure so long as one of the component KEMs is.

17. Appendix B

Component Signature Algorithm

Component Encryption Algorithm

Proposals (mainly clarifying)

18. Section 7.2

to use it, the value should be HEX-decoded and used in binary form.

to use it, the value MUST be HEX-decoded and used in binary form.

Rationale: For interoperability purposes this type of encoding should be clearly indicated.

19. Section 7.3

• Pair equivalent levels.

• Pair equivalent levels (except for RSA, especially RSA2048, which were included due to their massive use).

Rationale: security strength of RSA2048 is 112 bits and RSA3072/4096 128 bits.

20. Section 8.1.1

salt: optional salt value (a non-secret random value). In this
document this parameter is unused, that is it is the zero-length
string "".

salt: optional salt value (a non-secret random value). In this
document this parameter is unused, that is it is the string of
HashLen zeros.

Rationale: Section 2.2 RFC 5869:
salt optional salt value (a non-secret random value);
if not provided, it is set to a string of HashLen zeros.

21. Section 8.2

kdf identifies the key-derivation algorithm. Note that the Key
Derivation Function (KDF) used for CMS RecipientInfo process MAY
be different than the KDF used within the Composite ML-KEM
algorithm or one of its components.

kdf identifies the key-derivation algorithm. Note that the Key
Derivation Function (KDF) used for CMS RecipientInfo process (to calculate the KEK key) MAY be different than the KDF used within the Composite ML-KEM algorithm (to calculate the shared secret ss).

Rationale: The removal of the phrase “or one of its components” results from the fact that the traditional component uses RSA-OAEP (and not RSA-KEM as in the previous versions of the document) or uses a simplified version of DHKEM - see Section 3.2. Otherwise, these KDF functions would have to be defined in this document.

Regards