Please avoid squatting on codepoints

[dkg]

The draft currently stakes out claims for codepoints in the active range of asymmetric keys, though the values are still in flux. That seems dangerous.

If we want concrete values for interoperability testing, feel free to use experimental codepoints (100-110) while the draft is still in flux.

We'll stabilize on formal codepoints later in the process once we know what we're getting into.

[falko-strenzke]

I am not entirely sure how to understand this proposal, as the draft currently defines 6 KEM algos and 8 signature algos, so a total of 14 altogether which is more than fits into the range 100-110. To be closest to the current proposal would thus be to use 100 - 113.

The – possibly more consistent – alternative would be to start from 111 in order to spare the anyway insufficient range of experimental code points entirely.

[dkg]

Please see #86 for one possible way to use experimental codepoints while the draft is still in flux

[TJ-91]

I like the clever approach to divide between NIST / Brainpool curves. I'd still prefer not to have an overlap since it makes interop testing more tedious and error-prone. Also, it introduces the overhead to keep separate branches up to date.

[dkg]

@TJ-91 i like your suggestion to just leave the MAY algorithms explicitly TBD and only use experimental codepoints for the SHOULD and MUST algorithms. Would you prepare a pull request with that?

[TJ-91]

See #87