Ketan Talaulikar has entered the following ballot position for draft-ietf-cose-dilithium-09: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Just some easy to address comments related to references that perhaps rise to the level of DISCUSS. Sections 3 and 5: The URLs [IANA.jose] and [IANA.cose] are informative references? Section 8: Several RFCs here that should be normative or informative references? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. Please find below some comments and suggestions to improve the clarity of this document. General: s/NIST/US NIST and S/FIPS/US NIST FIPS - we want to be clear this is coming from an US entity Section 1: s/draft-ietf-cose-key-thumbprint/RFC9679 Perhaps change "as described in [FIPS-204] with JOSE and COSE" to "as described in [FIPS-204], in conjunction with JOSE and COSE." ? Perhaps "can be compared according the procedures..." should be "can be compared according to the procedures..." ? Section 3: Keep the actions for IANA in the IANA considerations sections alone. Perhaps instead of "This document requests the registration of the following key types in [IANA.jose]:", how about "This document introduces the following key types (see section 8.1.x for details):" This can be done for other similar sentences (in this section as well as section 5). The URLs [IANA.jose] are better placed in the respective IANA consideration sub-sections? s/use of multiple key type/the use of multiple key type s/key parameters are base64url encoded/the key parameters are base64url encoded Perhaps, instead of "Some algorithms might require or encourage additional structure or length checks for associated key type parameters", would this be more clear - "Some algorithms may require or recommend additional structure or length checks for associated key type parameters." ? ... not sure what is meant by encourage here? Section 5: Suggest "See the ML-DSA Private Keys section of this document for more details." change to "See Section 4, ML-DSA Private Keys, for further details." Perhaps instead of "ML-DSA might not be the best choice for use cases that require small keys or signatures." it could be "ML-DSA may not be suitable for use cases requiring small keys or signatures." ? _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
