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

[Watson Ladd <[e-mail]>]

On Wed, Nov 5, 2025 at 9:06 AM Natanael <[e-mail]> wrote:
>>
>> 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).

The OIDs don't contain the label at all.

We changed this doc to avoid wanting a MISREF to duplicate values, and
then we ended up in this mess when one duplicate changed. There's a
lot to be said at a higher level about the forces that lead to this
temptation (and kitten had to do similar with SPAKE2, so I've also
been in this situation) but it's very unfortunate.

>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim