Re-assign all code points

[baentsch]

As correctly questioned in #556 (comment) the code points in this project are not aligned with IANA, most notably code points from non-standardized algorithms are not in the "Reserved for private use" space.

This issue is to suggest changing that -- ideally in a long-term easily maintainable manner, best fully automatic during algorithm changes done to the underlying liboqs.

[pi-314159]

Talking about resigning codepoints: Since Chrome 131 was released today (Edge 131 this Thursday) and Firefox 132 was released on October 29, we can drop Kyber support. Additionally, to simplify maintenance efforts, we can reverse the order of all X25519 hybrids.

I suggest doing this with the liboqs 0.12.0 or 1.0 release.

@baentsch @bhess

[baentsch]

Following the mantra "less code is more secure code" I'm all for simplification and easing maintenance and would be OK dropping all Kyber support (incl. "hybrid order juggling") for good (also making the implementation effort for this issue quicker). Objections, @dstebila @SWilson4 ?

[dstebila]

I've created open-quantum-safe/liboqs#1989 about dropping Kyber support.

[baentsch]

Another code point proposal to track/implement: https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00

[tomato42]

I think that ML-DSA codepoints are especially important, so I've filed #578 to track them.

[baentsch]

I think that ML-DSA codepoints are especially important, so I've filed #578 to track them.

Well, this doesn't really fit this issue: Adapting the ML-DSA code points and OIDs is run-of-the-mill business that has nothing to do with the "general overhaul" (beyond non-standardized IDs) that this issue suggests: As the code base gets updated to actually include the standardized code (in this case, as per #568) the corresponding code points (and OIDs) get updated. That said, your issue really should be a PR feedback... Just used it that way :)

[tomato42]

@baentsch aah, I took #561 (comment) as you wanting to use this issue for cleanup in general, sorry about that 🙂

will take a look at #568

[baentsch]

@baentsch aah, I took #561 (comment) as you wanting to use this issue for cleanup in general, sorry about that 🙂

I wouldn't want to clean up things that are not even available for tidying :-)

will take a look at #568

Thanks.

[RodriM11]

Hi! Regarding this issue, I had a couple questions:

• Regarding the handling of code points for KEM procedures, should "old" code points be re-assigned into IANA-compliant ones? (I imagine the answer is no, but wanted to asked just in case). Also, is there any specific reason to keep those 'old' schemes in the generate.yml (specifically, 2º round BIKE, HQC and Kyber, plus Kyber 90's) ?
• The re-assignation of code points to IANA "Reserved for private use" (i.e. 65024-65279) can either be done manually or try to automatize it, as @baentsch suggested. Regarding the latter, the way I was thinking it was to complete the generate.yml with the next available code point (by checking the already established ones on the file). This way, to add a new configuration, you would add family, name_group, etc.. to generate.yml and generate.py would add nid, nid_hybrid and nid of extra_nids. The problem of this approach is that generate.yml has a number of peculiarities that YAML libraries not always handle (although I am very much not versed on Python and YAML). Based on a quick search, it seems that a different python module would be needed to handle comments (e.g. ruamel.yaml), and that some modifications would happen to the file (the hyphen and EOL before each new scheme, the spaces of signature's mix_with configuration, etc... A different approach if this is not desired (not automatic) could be to include a function that provides the next available code group, from those available, when a new configuration is added to generate.yml. But, as I said, I am not versed on this so any suggestion or different approach would be greatly appreciated.

[RodriM11]

Additionally, that automatic behavior could also be translated to signatures (for future additions): the code_point field would be filled automatically with the next available element from the range 0xfe00 to 0xffff, once the remaining fields have been filled to add a new configuration.

Update: I have tried ruamel.yaml to see how generate.yml is affected, and it seems, since hyphens are used in two different forms (before each configuration, in a separate line, and in the same line within current definitions, for example) the hyphen before each configuration gets pulled to the first line of the configuration. Also, the spaces in the 'mix_with' field is modified. But, other than that, it could be a plausible solution to automatically fill the generate.yml with an IANA-compliant code point for each new configuration added.

[RodriM11]

@baentsch any thoughts?

[baentsch]

Oops -- that slipped my attention; thanks for tagging me again @RodriM11 -- oqsprovider in my view is a bit in "hibernation mode" at least until openssl 3.5 alpha appears (and apparently not just in my view :).

should "old" code points be re-assigned into IANA-compliant ones?

No: Inactive code points should remain as-is:

Is there any specific reason to keep those 'old' schemes in the generate.yml (specifically, 2º round BIKE, HQC and Kyber, plus Kyber 90's) ?

Yes: That information is used to generate documentation allowing people to understand which code/algorithm version is running somewhere if the documented IDs appear in traces.

it could be a plausible solution to automatically fill the generate.yml with an IANA-compliant code point for each new configuration added

That would be nice. If I get your proposal right (?) you'd recommend running a script to generate "generate.yml" to avoid (failure-prone/tedious) manual edits? If so (?) a PR to resolve this issue that way would be very welcome indeed.

[RodriM11]

If I get your proposal right (?) you'd recommend running a script to generate "generate.yml" to avoid (failure-prone/tedious) manual edits? If so (?) a PR to resolve this issue that way would be very welcome indeed.

Yes, that would be the idea. My only "concern" is that generate.yml has some peculiarities (e.g. the hyphen and EOL before each new scheme, the spaces of signature's mix_with configuration, etc...) and to maintain as much as possible, a new Python package would be required (e.g. ruamel.yaml), and even then, some modifications to generate.yml would happen. If that is acceptable yes, (I think) I would be able to automatize the process.

PD: if those peculiarities are just a 'beauty' artifact (as I believe), I could avoid using ruamel.yaml and just get rid of them. Let me know what you think about the approaches.

[baentsch]

some modifications to generate.yml would happen

I personally don't mind at all about such changes as long as they don't impact users (or the build logic). But even then, we can declare it part of #375 :) So, please go ahead. And cleaning up stuff, particularly if that avoids dependencies is always a Good Thing (and if only to ease maintainability :).