Currently the draft specifies KMAC as the only MTI KDF algorithm. There was a concern from LAMPS (Deb Cooley) that some implementations might not have access to SHA3/KMAC at the CMS level. That is, SHA3 may only be at the crypto level (maybe even in an HSM or TPM) since ML-KEM requires it, but many other things don't. On the other hand, low-resource devices may want to only support SHA3 and not SHA2.
It was mentioned in LAMPS IETF 119 that we could give the option for either to be supported, with good reasoning to it doesn't get challenged by IESG.
Suggested text, before I have time to actually write a PR:
One of KMAC{128,256} or HKDF-with-SHA{256,512} MUST be supported. It is RECOMMENDED that both be supported.
and then specific details for each of the security variants.
KMAC uses SHAKE (SHA3). HKDF-with-SHA2-* uses SHA2.
Currently the draft specifies KMAC as the only MTI KDF algorithm. There was a concern from LAMPS (Deb Cooley) that some implementations might not have access to SHA3/KMAC at the CMS level. That is, SHA3 may only be at the crypto level (maybe even in an HSM or TPM) since ML-KEM requires it, but many other things don't. On the other hand, low-resource devices may want to only support SHA3 and not SHA2.
It was mentioned in LAMPS IETF 119 that we could give the option for either to be supported, with good reasoning to it doesn't get challenged by IESG.
Suggested text, before I have time to actually write a PR:
and then specific details for each of the security variants.