Hi Med, I have addressed your comments and other IESG comments here: https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/26
Let me know if I missed anything. Inline for the rest. On Wed, Oct 1, 2025 at 1:39 PM Mohamed Boucadair via Datatracker < [email protected]> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-cose-dilithium-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi Michael and Orie, > > Thanks for the effort put into this specification. > > Thanks also to Tiru Tirumaleswar Reddy for the OPSDIR review and to the > authors > for engaging and proposing changes. I went through > https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/25/files and > trust > this PR will be merged. The explanation about the seed only design choice > and > also calling out some ML-DSA deployment challenges are appreciated. > Agreed, I should have merged this sooner, it is merged now. > > I also trust the examples were validated. > They are generated here: https://github.com/cose-wg/draft-ietf-cose-dilithium/tree/main/examples I'm still fearful I've made mistakes in these, so for anyone reading this, if you want to ❌✅ cross check me, its very much appreciated. > I have very minor comments: > > # Redundant IANA considerations > > Not sure why IANA requests are repeated twice in the document (Sections > 3/4/5 > and then IANA Section). I think it is better to have this in one single > place. > Done. > > # Who is the target of this guidance? > > CURRENT: > When registering new algorithms, use of multiple key type parameters > for private information is NOT RECOMMENDED. > This guidance is directed towards specification authors who are using this key type with new algorithms (for example SPHINCS Plus / Falcon)... but really it's towards anyone considering making a private key format, optionality is dangerous there. I did add some text to try to make this clearer. > > # Citations > > Several RFCs are provided in the text but are not cited as references, > e.g., > RFC 9054 and RFC 7518. Please check through the doc. > Thank you, I think I have addressed these. > > # Regional Matters > > Please s/FIPS 204/US FIPS 204 in the abstract and s/NIST/US NIST in > Section 4 > Done. > > Cheers, > Med > > > >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
