Hi Jim! Thanks for the quick response. You refinements below are an improvement over mine. Thanks for making them.
Regards, Roman > -----Original Message----- > From: Jim Schaad <[email protected]> > Sent: Tuesday, June 9, 2020 12:17 AM > To: Roman Danyliw <[email protected]>; 'The IESG' <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > 'Ivaylo Petrov' <[email protected]> > Subject: RE: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: > (with COMMENT) > > > > -----Original Message----- > From: Roman Danyliw via Datatracker <[email protected]> > Sent: Monday, June 8, 2020 8:23 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > Ivaylo Petrov <[email protected]>; [email protected] > Subject: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with > COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-cose-hash-algs-04: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for extending COSE for this additional use. > > ** I added my thoughts on the Section 2 language to the email thread of > Barry’s ballot > > ** Per “To distinguish between these two cases, a new value in the > recommended column of the COSE Algorithms registry is to be added. > "Filter Only" indicates that the only purpose of a hash function > should be to filter results and not those which require collision > resistance”, I would recommend: > > NEW: > To distinguish between these two cases, a new value in the recommended > column of the COSE Algorithms registry is to be added. "Filter Only" > indicates > that the only purpose of a hash function should be to filter results and it > is not > intended for applications which require a cryptographically strong algorithm > is > needed. > > It doesn’t change the intent, but it does generalize to all the security > properties > we might want of a hash algorithm. > [JLS] Yes that makes sense, but I removed the trailing "is needed" because it > does not read well. > > ** Section 5. Since collision and second-preimage attacks are mentioned, for > completeness it would be worth mentioning the need for preimage resistance > for cryptographic usage too. > > ** Editorial nits: > > -- Abstract. Editorial. The abstract has an explicit reference, > [I-D.ietf-cose- > rfc8152bis-struct], which abstracts are not permitted to have. > [JLS] ACK - I left it this way because it is a draft and not an RFC to make > sure > that it is highlighted for the RFC Editor. > > -- Section 2.1. Editorial. s/this could /This could/ [JLS] Already caught. > > -- Section 3.1. Editorial. s/assign a point/assign a code point/ [JLS] Done. > > -- Section 3.2. Editorial. > > OLD > Locations that use this hash function > need either to analysis the potential problems with having a > collision occur, or where the only function of the hash is to > narrow the possible choices. > > NEW > Applications that use this hash function need either to analyze the potential > impact with having a collision occur, or use it only where the function of the > hash is to narrow the possible choices. > [JLS] This was already rewritten in response to comments from Barry. > > Use of this hash function needs analysis of the potential > problems with > having a collision occur, or must be limited to where the function of the > hash is > non-cryptographic. > > -- Section 3.3. Per “The pair of algorithms known as SHAKE-128 and SHAKE-256 > are the instances of SHA-3 that are currently being standardized in the > IETF”, it > isn’t clear this sentence will age well. > [JLS] It may not age well but it is why these are the ones in the document. > Perhaps "currently being standardized in the IETF. This is the reason for > including these algorithms in this document." > > -- Section 4. Typo. s/preseved/preserved/ [JLS] Fixed > > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
