[lamps] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

[Mike Ounsworth <[e-mail]>]

Thanks Carl,

A few things are going on here.

First, I agree that the text I wrote in -09 is not as clear as it could be. I'll do another pass.

Second, the change from OID-based Domain Separators are part of a larger effort to harmonize the LAMPS Composites with the parallel Hybrid KEM work in CFRG and HPKE. Part of that means switching the KEM side to use HPKE-style labels, and registering the LAMPS Composite KEM in the HPKE Algorithm Registry. If we're that on the KEMs side, then for consistency, we should do it on the Sigs side.


---

Mike Ounsworth




________________________________
From: Carl Wallace <[e-mail]>
Sent: Tuesday, September 30, 2025 6:14 AM
To: Mike Ounsworth <[e-mail]>; Bas Westerbaan <[e-mail]>; Mike Ounsworth <[e-mail]>
Cc: Russ Housley <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [lamps] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

Inline… From: Mike Ounsworth <Mike. Ounsworth=40entrust. com@ dmarc. ietf. org> Date: Monday, September 29, 2025 at 10: 56 AM To: Bas Westerbaan <bas=40cloudflare. com@ dmarc. ietf. org>, Mike Ounsworth <ounsworth+ietf@ gmail. com> Cc: 


Inline…



From: Mike Ounsworth <Mike.Ounsworth=[e-mail]>
Date: Monday, September 29, 2025 at 10:56 AM
To: Bas Westerbaan <bas=[e-mail]>, Mike Ounsworth <[e-mail]>
Cc: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [lamps] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)



Hi Bas,



Thank you for your feedback.



First, I have an extremely busy week at $dayjob, and I am not sure that I will have another chance to do a big round of edits before the WGLC closes. The easiest for me would be if you open a PR on github with your suggested changes.



https://github.com/lamps-wg/draft-composite-sigs<https://urldefense.com/v3/__https://github.com/lamps-wg/draft-composite-sigs__;!!FJ-Y8qCqXTj2!ZqblfIDU002Ld569Ou_dq-LcCtSrOPxvb-BgXkiiPrHR-sDXDdf7dI7DtTpcuCAoz_O6YSvnH6KVQ8FQL4_d-eI1$>



I'll address a few of your points, and explain why I made the changes the way I did.







"Label" vs "len(Label) || Label"



We do not want to make a breaking change to the construction at this point, unless there is an actual security issue. As I understand this, you are not pointing out a security issue with this spec, but rather that people might go off-spec in a dangerous way. I don't see that as important enough to be worth breaking all the test vectors. If you want to suggest alternate text, that would be great.



[CW] I wasn’t sure what to make of the new language regarding labels. Without always prefixing the length, it boils down to defining the label as the length prefix plus value for “user supplied” values, which doesn’t seem particularly useful. In any case, what is a “user supplied” value? Section 4.2 states “a signature label which is specific to each composite algorithm.” This suggests the need for a registry. One nit, the text also references the now deleted section titled “Signature Label Values”, which was really “Domain Separator Values” section. Personally, I thought the old practice of using the encoded OID was simpler.

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.