p384_mlkem1024 hybrid added

[bencemali]

We would like to use a NIST P curve + ML-KEM hybrid and compliance reasons would mandate using P-384 and ML-KEM-1024.
We found that P-384 is the most accepted P-curve. See CNSA 1.0.
From the ML-KEM variants, level 5 will be the most widely accepted. See CNSA 2.0.
Having a P-384 + ML-KEM-1024 hybrid could be useful.

[bencemali]

We would also like a stable oid for this hybrid and we suggest our internal, under Tresorit. The oid is 1.3.6.1.4.1.42235.6.
See Tresorit OID.

[baentsch]

Thanks for this contribution, @bencemali ! It seems you essentially added an entry to "generate.yml" and correctly built and formatted the code -- so from that perspective the PR is OK. In light of #351 I'm somewhat hesitant to merge this as-is, though: Could you point to a (draft) spec for this combination and would you be willing to take on OID management of this hybrid, e.g., change as and when it becomes standardized? If so, please add a corresponding (comment) entry at the top of "generate.yml" listing a contact (email address) and (draft) spec reference (or deployment case) for this new hybrid.

[bencemali]

Hi @baentsch, as far as we know there is no draft for this combination. The reason I included our oid in the pull request is to provide a fixed oid, just to make sure it doesn't constantly change in oqs-provider. We intended for this oid to be permanent, until (and if) it is standardized. Of course any other oid would suffice.

[baentsch]

We intended for this oid to be permanent, until (and if) it is standardized. Of course any other oid would suffice.

OK -- understood & makes sense. Please feel free to amend the PR by comment to state this (at the top of "generate.yml" or next to the OID). Otherwise, git blame will allow us to trace this in the future. A re-base to "main" would be nice to get CI to turn green, though.

[bencemali]

Thanks, @baentsch!

[baentsch]

Thanks for the contribution. Merged.