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 <[email protected]> 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 >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
