Elwyn, thanks for your review. I entered a No Objection ballot and requested a response to your review. Alissa > On Oct 28, 2019, at 7:30 PM, Elwyn Davies via Datatracker <noreply@xxxxxxxx> wrote: > > 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. > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
