Hi Lucas, Thank you for your comments, I am attempting to address them here: https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/14
May I add your name (Lucas Prabel) to the acknowledgements section? Regards, OS On Thu, Nov 21, 2024 at 4:57 AM Lucas Prabel <lucas.prabel= [email protected]> wrote: > Hello, > > > > I am pleased this document exists and think support for ML-DSA in JOSE and > COSE will prove useful, especially now that ML-DSA is being specified by > more and more working groups. After reviewing it, here are my comments: > > > > *Section 3* > > - typo: “paramaterized” --> “parameterized” > > - In Table 2, I would call the 2nd column “value” instead of “alg”. > Thanks I took both of these. > > > *Section 4* > > - I agree with Neil Madden and think this section is a bit underspecified. > In particular, I think it needs precise specification of the Key Parameters > associated with AKP. > I agree, I have attempted to address this feedback as part of the same pull request. > - In the given COSE example (Figure 2), key parameters are called “pub” > and “priv”, but called “public_key” and “private_key” in Section 8.14 and > 8.15. > Thanks for pointing this out, I aligned them. > - typo “the registration of the following algorithms in [IANA.cose]” → “the > registration of the following key type in [IANA.cose]” > Fixed. > > > *Section 5* > > - I think the first sentence can appear a bit confusing in its use of > "private key" as the term refers to two different things in its 2 > occurrences (in the 1st one, "private keys" encompasses both the seed and > its expanded representation, while in the 2nd, it only refers to the full > expanded key). FIPS 204 seems to be a bit clearer by using "private key" > exclusively to mean the full expanded private key. > I agree, hopefully it is better now. > > > *Other* > > I would like this document to clarify its stance on the use of HashML-DSA > from FIPS 204. Recent IETF discussions suggest moving away from including > HashML-DSA as an option, focusing instead solely on ML-DSA without > pre-hashing. For this document, while I think it was agreed that any > pre-hash specifications would be detailed in a separate draft if needed, I > think we should add a short sentence stating that this draft doesn't > include the pre-hash option. Besides, I think we should add some words > about how to handle the ML-DSA context string. > I agree, I hope what I have is sufficient to address this. > > > > > Thanks for your work, > > Best, > > > > Lucas > > > > *From:* Michael Jones <[email protected]> > *Sent:* mardi 19 novembre 2024 17:48 > *To:* [email protected] > *Subject:* [COSE] WGLC for draft-ietf-cose-dilithium > > > > Hi all, > > > > This message starts the Working Group Last Call (WGLC) for > https://www.ietf.org/archive/id/draft-ietf-cose-dilithium-04.html (ML-DSA > for JOSE and COSE), as was discussed at IETF 121 in Dublin. The WGLC will > run for two weeks, ending on Tuesday, December 3, 2024. > > > > Please review and send any comments or feedback to the working group. > Even if your feedback is “this is ready for publication”, please let us > know. > > > > Thank you, > > -- Mike and Ivaylo, COSE > Chairs > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
