IETF Last Call Review of draft-ietf-cose-hash-envelope-07
review-ietf-cose-hash-envelope-07-secdir-lc-sheffer-2025-10-19-00

Request Review of draft-ietf-cose-hash-envelope
Requested revision No specific revision (document currently at 10)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-10-10
Requested 2025-09-26
Authors Orie Steele , Steve Lasker , Henk Birkholz
I-D last updated 2025-11-18 (Latest revision 2025-11-15)
Completed reviews Genart IETF Last Call review of -08 by Linda Dunbar (diff)
Secdir IETF Last Call review of -07 by Yaron Sheffer (diff)
Secdir Telechat review of -09 by Yaron Sheffer (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Request IETF Last Call review on draft-ietf-cose-hash-envelope by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/vz6ff_TT2T0yfVlOhhzdSVMBK6Y
Reviewed revision 07 (document currently at 10)
Result Has nits
Completed 2025-10-19
review-ietf-cose-hash-envelope-07-secdir-lc-sheffer-2025-10-19-00
Overall the document is clear and mostly ready for publication.

- I suggest to add to the Terminology section a definition of "payload" and
"preimage".

- "Envelope Extended Diagnostic Notation" - this is unclear as text, is it
supposed to be a subsection header?

- It would be good to describe in detail the verifier's behavior (maybe an
actual list of steps), including the decision on regular/detached/hashed
payload.

- If content_type is not allowed, please mention that the payload is always
expected to be a bstr.

- Marking the new headers as critical is only a MAY. Should it be stronger? How
important is this for integrity?

- Sec. 5.1: the second half of this section is a long and convoluted sentence
("The approach...") that I find hard to parse.

- Encrypted hashes: I'm not sure if this is a real use case. But if it is, a
clearer recommendation on how to use this draft in that case would be better
than the current section.