[CFRG] Re: [lamps] Re: Re: [EXTERNAL] Re: [hpke] Re: Re: Re: Re: Cross-testing update on LAMPS Composite and cfrg-concrete-hybrid-kems

[Natanael <[e-mail]>]

>
> Den tis 4 nov. 2025 14:24Nick Sullivan <[e-mail]>
> skrev:
>
> Hi Richard,
>
> This outcome seems reasonable to me. Please go ahead and update the draft
> with the semantic labels for MLKEM768-P256, and MLKEM1024-P384.
>
> From my perspective as CFRG chair, there is one last bikeshed to paint:
> the label for MLKEM768-X25519. It's clear from this discussion thread that
> having ASCII art, and especially ASCII art that contains special characters
> like backslashes, is undesirable to most of the group. On the other hand,
> some in the group have expressed interest in using this draft as an
> opportunity to define an RFC reference that establishes a code point for an
> X25519-MLKEM hybrid that is interoperable with deployed versions of X-Wing
> that contain the ASCII label. These are at odds.
>
> I want to propose an alternative that could resolve this conflict and help
> us move past these issues. Here's the proposal: we define the following
> three codepoints in the body of the document, updating them all to use
> semantic labels:
> MLKEM768-P256, label: MLKEM768-P256
> MLKEM1024-P384, label: MLKEM1024-P384
> MLKEM768-X25519, label: MLKEM768-X25519
>
> Then, in the appendix, we include a fourth codepoint to document the
> legacy X-Wing construction with name "X-Wing" and label "\.//^\" so that
> existing deployments have a unique and memorable codepoint they can use and
> reference.
>
>
As mentioned by Filippo, it would be problematic to have 2 permitted
labels. It would inevitably lead to some recognizing only one label or not
realizing the algorithms are one and the same.

If the label will change to descriptive, then however it could make sense
to define the older ASCII art label BUT also flag it as deprecated,
permitting it to be parsed but not emitted (allowing older implementations
to update incrementally without breaking compatibility).

>