Remove unmanaged KEM OIDs

[baentsch]

Fixes #520

[dstebila]

Do we have any idea of who might be using this functionality? For example, the IETC PQC certificate hackathon group? If so, would be good to know if/how this impacts them. @praveksharma have you been in recent contact with them at all? Or perhaps experiment in the NCCoe -- @christianpaquin any insight from NCCoE?

Did you consider removing our hard-coded OIDs but still letting it be enabled at runtime if the relevant environment variable is set? (Without needing to regenerate from generate.yml and rebuild.)

[christianpaquin]

For example, the IETC PQC certificate hackathon group? If so, would be good to know if/how this impacts them. @praveksharma have you been in recent contact with them at all? Or perhaps experiment in the NCCoe -- @christianpaquin any insight from NCCoE?

The NCCoE follows closely the work of the IETF hackathon, so their feedback would be helpful. Can you give some guidance, @johngray-dev?

[praveksharma]

Do we have any idea of who might be using this functionality? For example, the IETC PQC certificate hackathon group?

I haven't had recent contact regarding OID mappings but the relevant documentation in the IETF repo does not list any of the OIDs affected by this PR.

[baentsch]

Did you consider removing our hard-coded OIDs but still letting it be enabled at runtime if the relevant environment variable is set? (Without needing to regenerate from generate.yml and rebuild.)

No. I have never received positive nor negative feedback regarding this feature (added originally in support of an IETF hackathon) so consider it safe to drop for unassigned OIDs. Again, if someone wants to test any of the KEMs without OIDs, they should have an idea about the OID -- it's otherwise impossible to test :) -- and this PR is also meant to create an incentive to contribute such ideas to the community.

Also, please note again that this is a completely voluntary effort on my part: I have to be(come) more efficient in how many features/options I keep supporting in my unpaid time. Things are even more acute as I have to now devote (waste) my time to working around (or using their processes to revert) problems created by LinuxFoundation: That org has easily cost (lost) me several hundred work hours this year....

But looking at the code again, it seems I created it such to enable the feature you're asking for @dstebila . It really would be nice if more people were contributing to the project..... I seem to forget more about the code than all other contributors combined added :-/

I haven't had recent contact regarding OID mappings but the relevant documentation in the IETF repo does not list any of the OIDs affected by this PR.

Thanks for that re-confirmation, @praveksharma . Supports my line of thinking.

[SWilson4]

Did you consider removing our hard-coded OIDs but still letting it be enabled at runtime if the relevant environment variable is set? (Without needing to regenerate from generate.yml and rebuild.)

...

But looking at the code again, it seems I created it such to enable the feature you're asking for @dstebila . It really would be nice if more people were contributing to the project..... I seem to forget more about the code than all other contributors combined added :-/

I confirmed (locally) that the en/decode tests do indeed pass for the NULL-ified KEMs when run with an appropriate environment variable set.

[baentsch]

Thanks for this catch @ghen2 -- as per the title of the PR this is not the intention given that generate.yml does contain IDs for x25519_mlkem768 . So need to debug what's going wrong here...

Now I have to correct myself: There is a code point but no OID for x25519_mlkem768. So the logic is correct. @ghen2 Can you please confirm what OID you are aware of for that algorithm? Same with your comment on the MLKEM512 hybrids: They do have code points, so should not be NULL. What leads you to think otherwise?

In other words, the PR is OK.

[ghen2]

OIDs denoted with NULL are not maintained and may lead to errors in code execution. [...]

This comment gave the impression that those algorithms would no longer be supported.
But for OID's this only affects X.509 usage?

[baentsch]

This comment gave the impression that those algorithms would no longer be supported.

Ah; no, this never was the intention. Hence there's a "Yes" for all those algs higher up in the list where the code points are listed.

But for OID's this only affects X.509 usage?

Exactly. No OID means no X.509 storage/retrieval. Rest of functionality unaffected. If you'd have a better way to formulate things, by all means please provide suggested wording.

[dstebila]

I confirmed (locally) that the en/decode tests do indeed pass for the NULL-ified KEMs when run with an appropriate environment variable set.

Thanks, Spencer!

[baentsch]

Rebase necessary because #524; I'm not entirely sure I did catch everything right, so could someone please (re-)review as and when CI passes?

[SWilson4]

Rebase necessary because #524; I'm not entirely sure I did catch everything right, so could someone please (re-)review as and when CI passes?

Looks like the rebase went OK to me. Please do let me know regarding #522 (comment). After that's resolved it's ready to go from my perspective.

[baentsch]

Rebase necessary because #524; I'm not entirely sure I did catch everything right, so could someone please (re-)review as and when CI passes?

Looks like the rebase went OK to me. Please do let me know regarding #522 (comment). After that's resolved it's ready to go from my perspective.

I'm not sure what I should be doing there: I agreed to that right after you asked. Or are you seeing something else? Maybe the "Pending" marker says this didn't get posted?

[SWilson4]

I'm not sure what I should be doing there: I agreed to that right after you asked. Or are you seeing something else? Maybe the "Pending" marker says this didn't get posted?

"Pending" comments (created as part of a code review) are queued in a batch to be published when the "submit review" (or something similar) is pressed. Until then they're not public.

[baentsch]

@ghen2 I just marked an open discussion resolved such as to move this PR forward and as per the discussion here taking your Thumbs up as agreement to close this issue. Please comment soon if you do not agree as we'll otherwise merge this tomorrow.

[ghen2]

Thanks @baentsch, I couldn't mark it resolved myself, or I would have.