Last Call Review of draft-ietf-cose-hash-sig-05
review-ietf-cose-hash-sig-05-genart-lc-davies-2019-10-28-00

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.