Add P-256 variant, use HKDF-Extract instead of HKDF as the combiner KDF, and add HPKE integration section

[chris-wood]

This will need to be modified based on #94, in particular to update the DeriveKeyPair description, but the rest of the change in this section should stand on its own.

Closes #93, #87, #86

[chris-wood]

@ounsworth @johngray-dev I'll revert the HKDF drop for now, replacing it with HKDF-Extract (as discussed at IETF 121), but I'd like to discuss this again in the future.

[chris-wood]

@ounsworth @johngray-dev I updated this PR. One question that came up was what KDF do we want to use for turning input seeds into seeds for the underlying component KEMS? To elaborate, the HPKE DeriveKeyPair function takes a seed as input. The specification of DeriveKeyPair currently expands that seed into two components -- one for each component KEM. The first piece goes to ML-KEM.KeyGen_internal, and the second piece goes to the traditional KEM's DeriveKeyPair function. Currently, the PR uses SHAKE256 as the XOF to do this expansion, exactly as X-Wing does. But if we believe the premise that SHA3 will not be available in all environments, we might want to do something else.

(To be clear, I don't think it's reasonable to believe that SHA-3 implementations will not be available. This is new code, after all, and new code could just as well add SHA-3 if it's not available.)

In any case, could you please have a look and let me know what you think? This is the final piece of the puzzle before we can get some actual HPKE code points!

[johngray-dev]

Hi Chris. Thanks for the update. I'm okay with these changes except that I noticed you switched the prototype OIDs back to ending with .21 ... .29... Those were from the previous version and won't be compatible with this update since we removed the ASN.1 sequence wrappings (so this upcoming -06 version will not be binary compatible with the last version). So if you could update the OIDs to use .30 to .39 then we wouldn't cause prototype interoperability issues. Eventually we will get official OIDs from IANA, but for people wanting to interoperate now we use these prototype OIDS. I'm ok with adding the MLKEM768-ECDH-P256 one as well. So re-numbering the OIDs starting at 30 makes sense. For example:

2.16.840.1.114027.80.5.2.30   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-RSA2048
2.16.840.1.114027.80.5.2.31   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-RSA3072
2.16.840.1.114027.80.5.2.32   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-RSA4096
2.16.840.1.114027.80.5.2.33   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-X25519
2.16.840.1.114027.80.5.2.34   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-ECDH-P256
2.16.840.1.114027.80.5.2.35   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-ECDH-P384
2.16.840.1.114027.80.5.2.36   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM768-ECDH-brainpoolP256r1
2.16.840.1.114027.80.5.2.37   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM1024-ECDH-P384
2.16.840.1.114027.80.5.2.38   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM1024-ECDH-brainpoolP384r1
2.16.840.1.114027.80.5.2.39   entrust-Algorithm-ExplicitComposite-KEM.id-MLKEM1024-X448

That would also mean you need to update the DER Encoded OID table again. The ASN.1 module will also need to be updated to add the new MLKEM768-ECDH-P256. Other than that I think the pull looks great.

[ounsworth]

@chris-wood I think this PR is trying to do too much all at once, which makes it hard to review. It would be better if this was broken out into multiple PRs so that we can merge the P-256 thing while we discuss the other parts.

[ounsworth]

@chris-wood

One question that came up was what KDF do we want to use for turning input seeds into seeds for the underlying component KEMS?

... expands that seed into two components -- one for each component KEM. The first piece goes to ML-KEM.KeyGen_internal, and the second piece goes to the traditional KEM's DeriveKeyPair function.

But this is explicitly FIPS-disallowed because FIPS 203 / 204 do not allow a KDF in between your DRBG and Keygen_internal. This is exactly the reason that X-Wing has its own LAMPS draft and is not part of this draft -- X-Wing does not care whether you can make a FIPS-certified implementation of it, but this draft does.

I consider any kind of combined KeyGen to be a harmful change to this draft and I will reject any PRs that do that.

[ounsworth]

(To be clear, I don't think it's reasonable to believe that SHA-3 implementations will not be available. This is new code, after all, and new code could just as well add SHA-3 if it's not available.)

I don't particularly care one way or another, but the request for SHA2 combiners came from Deb Cooley on behalf of NSA. Here's the PQUIP 118 recording where she made her case: https://youtu.be/W46QrMvlLZU?feature=shared&t=5655

Joe Saloway made a similar request (but not on-recording). If you want the SHA2 combiners to be ditched, then you'll need to get Deb and Joe to withdraw their requests for it.

[ounsworth]

I'll open a separate PR to add the P-256 variant.
I'm ok in principle with adding an HPKE Integration section, but let's have that in its own PR cause I think we'll have to do a few iterations on it to balance the requirements of HPKE and PKI (particularly around KeyGen).

[johngray-dev]

Separating the items into their own issues will make it easier to track down the road, so I'm good with these suggestions.