OASIS PKCS 11 TC

Hi Bob,

A nit, section 1.4's Table 11 heading is incorrect and mentions Diffie-Hellman rather than ML-KEM.

More substantially, I think that Table 11 should not have Wrap and Unwrap checked for the ML-KEM mechanism and that the ML-KEM mechanism section should not include K-PKE. I think that was your intention, but the current draft still has it in there. If we want K-PKE support then I think it should be a different mechanism not a different behavior of the ML-KEM mechanism based on which function is called.

Sincerely,

Jonathan

Hi Bob,

I had a couple more questions on draft 5 as well.

The section on ECDH and ECDH-C states that "For C_Encapsulate, an ephemeral key pair is generated.".  The current specification supports two key-pair generation mechanisms for CKK_EC key pairs.  But it isn't clear which mechanism is supposed to get used to generate the ephemeral key pair. I believed we discussed this on the last call, but I can't remember what the conclusion was.  Do we leave it up to the implementation? Do we make it specifiable by the caller?  I don't think we should leave it undefined.

The section on the ML-KEM key agreement still states "For C_Encapsulate and C_Decapsulate the length controls the output of the ML-KEM internal KDF".  The internal KDF was part of the Kyber specification, but was removed in the FIPS 203 draft, and I haven't heard any indication that it will be added back in in the final version of FIPS 203.  I think in our earlier email exchanges that you suggested that "we will need to add a KDF mechanism", but there hasn't been any updates related to this. Did you have other intentions?

Thanks

Darren

Hi Bob,

A nit, section 1.4's Table 11 heading is incorrect and mentions Diffie-Hellman rather than ML-KEM.

More substantially, I think that Table 11 should not have Wrap and Unwrap checked for the ML-KEM mechanism and that the ML-KEM mechanism section should not include K-PKE. I think that was your intention, but the current draft still has it in there. If we want K-PKE support then I think it should be a different mechanism not a different behavior of the ML-KEM mechanism based on which function is called.

Sincerely,

Jonathan

Hi Bob,

A nit, section 1.4's Table 11 heading is incorrect and mentions Diffie-Hellman rather than ML-KEM.

More substantially, I think that Table 11 should not have Wrap and Unwrap checked for the ML-KEM mechanism and that the ML-KEM mechanism section should not include K-PKE. I think that was your intention, but the current draft still has it in there. If we want K-PKE support then I think it should be a different mechanism not a different behavior of the ML-KEM mechanism based on which function is called.

Sincerely,

Jonathan