@ounsworth this is a dupe of #87, I think?

In any case, I would recommend just dropping HKDF altogether. Since you're composing with ML-KEM, you already have SHA-3 available, so you might as well just use SHA3-256 as the one KDF across the board. What do you think?

In any case, I would recommend just dropping HKDF altogether. Since you're composing with ML-KEM, you already have SHA-3 available, so you might as well just use SHA3-256 as the one KDF across the board. What do you think?

Aww dude, you're like a year late to this debate. Both Joe Saloway and Deb Cooley were adamant that just because you have an ML-KEM implementation (potentially in a USB smartcard or something) does not mean that you have SHA3 available in, say, the Outlook S/MIME implementation that's gonna do the KEM Combining.

We have spent an inordinate amount of time fine-tuning a range of SHA2 and SHA3 offerings that everyone involved are happy with. Please don't re-open this can of worms.

@ounsworth this is a dupe of #87, I think?

Certainly related. There's a much larger discussion going on relating to how to make the SHA2-based combiner FIPS compatible. Russ is currently proposing that we ditch HKDF and specify raw usage of HMAC. This also has implications for CMS in general since the KEMRecipientInfo RFC that we just published (RFC 9629) has the same problem in that it is non FIPS compliant when used with id-alg-hkdf-with-sha256.

Please hold. I'll update github issues once my Outlook stops emitting smoke.

I'm sorry, but I don't buy the argument that ML-KEM will be available and SHA-3 will not. Where is discussion about this taking place?