Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cose-hash-sig-05 Reviewer: Elwyn Davies Review Date: 2019-10-28 IETF LC End Date: 2019-10-29 IESG Telechat date: Not scheduled for a telechat I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <" dir="auto">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. Document: draft-ietf-cose-hash-sig-05 Reviewer: Elwyn Davies Review Date: 2019/10/28 IETF LC End Date: 2019/10/29 IESG Telechat date: (if known) N/A Summary: Almost ready, There is one minor issue (barely above editorial) and a number of nits. I haven't checked the details of the HSS/LMS summary derived from RFC 8554 and I am taking the contents of the Appendix on trust! Major issues: None Minor issues: s1.1, last para: I found the note which provides particular motivation for this proposal rather obscure on first reading. After thinking about it, I now understand why this is here, but another sentence or so reinforcing the idea that getting the software distribution system post-quantum secure at the earlest opportunity is key to avoiding melt down should quantum computing develop more quickly than we might expect. Also referring to the SUIT WG is not future proof. Nits/editorial comments: s1, HASHSIG reference anchor: I would be inclined to stick with the 'standard' anchor for RFC 8554 i.e. [RFC8554]. s1, para 2: Expand DSA, ECDSA and EdDSA on first use ( RSA is claimed to be well-known). Arguably references for the various mechanisms might be desirable. s2, last para: s/The the/The/ s2 and subsections: The terminology and symbology used (e.g, || for concatenation) are (I believe) those defined in RFC 8554. This should be mentioned. s2.2, para 1: 'This specification supports only SHA-256': I think this is a cut-and-paste from RFC 8554. Suggest: s/This specification supports/[RFC8554] initially only supports/ and add at the end 'This specification would automatically support any such additional hash functions.' s4/s4.1: Rather than leaving an empty s4 and having a single subsection (generally frowned upon), the phraseology used at the start of s17 of RFC 8152 would be an improvement. s4: The security considerations of RFCs 8152 and 8554 are also relevant to implementations of this specification. s6: References to the relevant IANA registries for 'COSE Algrithms' and 'COSE Key Types' should be added. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
