Hi Lijun, Many thanks for your review. I tried to address most of the editorial points (line wrapping, P-256/P-384 naming consistency, the r/s wording in 4.5.1, the A0 tag explanation) and you can find the changes in the Editor's Copy on the Github repository: PQ/T Hybrid Composite Signatures for JOSE and COSE<https://ietf-wg-jose.github.io/draft-ietf-jose-pq-composite-sigs/draft-ietf-jose-pq-composite-sigs.html#name-ecdsa-encodings>.
For Appendix A.2, could you indicate what raised your concern in particular? On your suggestion to a normative reference to LAMPS instead: I agree that it would be a cleaner approach. We'll leave the current text as is for now and plan that change for a future revision if there are no objections from the group. Concerning the poll, it was taken during the JOSE session of the IETF 126 meeting, but anyone attending (onsite or remotely) could vote. In any case, we see it only as an indication, which is also why we'd welcome more input from both the JOSE and COSE mailing lists before settling this. Thanks again, Lucas From: Lijun Liao <[email protected]> Sent: 31 July 2026 18:19 To: Lucas Prabel <[email protected]>; JOSE WG <[email protected]>; cose <[email protected]> Subject: [jose] Re: draft-ietf-jose-pq-composite-sigs: ECDSA encoding Hi, First, "A poll was organized, with the following result: I prefer aligning with the LAMPS Composite document? Yes: 21 / No: 12 / No opinion: 10" Was the COSE WG consulted as part of this poll? I also have the following editorial comments: 1. Section 4.5.1, Ecdsa-Sig-Value (Signatures) "r and s are the raw, fixed-length, big-endian values already used today by [RFC7518] and [RFC9053] (32 bytes each for P-256, 48 bytes each for P-384)." Although r and s are typically fixed-length values for a given curve, they may also be encoded using fewer bytes if leading zeros are omitted. 1. Section 4.5.1, Ecdsa-Sig-Value (Signatures) Please also specify how many bytes are used to encode and decode the length field. Otherwise, implementers need prior knowledge of ASN.1 encoding rules. 1. Section 4.5.1, Ecdsa-Sig-Value (Signatures) Please wrap the long lines in the last code block. Also, after "parameters field", add the explanatory text: "A0: explicit tag 0". 1. Please use either P-256 / P-384 or secp256 / secp384 consistently throughout the document, rather than mixing the two naming conventions. 2. Please wrap the long lines in Table 7: JOSE/COSE Composite Label Values. 3. Please wrap the long lines in the examples in Appendix A. 4. I am not sure that the example in Appendix A.2 is conformant with the COSE specification. Best regards, Lijun (from cose WG) [Image removed by sender. Banner]<http://www.nio.io/> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. You may NOT use, disclose, copy or disseminate this information. If you have received this email in error, please notify the sender and destroy all copies of the original message and all attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
