Hi Tiru,
Thanks for your review.I have raised https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/25 towards addressing it.
I'll address the "why seed only" question here directly, I'm grateful for the opportunity to discuss this with the ietf community once more.
There is a thread which discussed this here: https://mailarchive.ietf.org/arch/msg/cose/j2Tyni0VPcq9zRlCKUA0iCO1TIE/
Russ and Tim both advocated for alignment (which we had in a previous version of the draft).
Richard, Neil, and MCR disagreed.
I've not been able to attend WG sessions, so I may lack helpful context regarding this, but the change was made as result of:
https://mailarchive.ietf.org/arch/msg/cose/mQXoYDTzpyqP-HGBzE2Y-l96g0I/
Daniel weighed in later: https://mailarchive.ietf.org/arch/msg/cose/ZYg6hwq8tzez0YxX-2Yt78mkjkE/
FWIW, I think COSE and JOSE made the correct call here.
We had an opportunity to make a *single private key representation*, and we took it.
Regards,
OS, (As an Author)
On Wed, Sep 10, 2025 at 8:32 AM tirumal reddy <kondtir@xxxxxxxxx> wrote:
Document: draft-ietf-cose-dilithium
Title: ML-DSA for JOSE and COSE
Reviewer: Tirumaleswar Reddy
Review result: "Ready with Issues"Hi,
I have reviewed this document as part of the Ops Area Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments are written primarily for the benefit of the Ops Area Directors. Document editors and WG chairs should treat them like any other Last Call comments.
The draft is well-written and addresses an important need for PQC migration. I have a few operational and deployment-related observations that may help improve the document:
1. ML-DSA produces significantly larger public keys and signatures compared to traditional algorithms. This size increase can create challenges for deployments with limited bandwidth, memory, or processing capacity. I suggest adding text to highlight it.
2. I suggest adding a reference to Section 8.3 of draft-ietf-lamps-dilithium-certificates, which explains the rationale for disallowing HashML-DSA.
3. It may be useful to add a note to explain why only the seed format was chosen for private keys, given that the LAMPS WG selected the expanded private key format to maximize interoperability with existing implementations.4. You may want to refer to the security considerations in https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/ and discuss if randomized signing is preferred over deterministic signing.Cheers,
-Tiru
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
