[COSE] Re: draft-ietf-cose-hash-envelope-07 ietf last call Secdir review

[Henk Birkholz <[e-mail]>]

Hi Yaron,

thank you for the excellent review. We tried to address your feedback in 
the latest draft:

> https://author-tools.ietf.org/iddiff?url1=draft-ietf-cose-hash-envelope-07&url2=draft-ietf-cose-hash-envelope-08&difftype=--html

Please find specific replies in-line.


For the I-D authors,

Henk

On 19.10.25 09:55, Yaron Sheffer via Datatracker wrote:
> Document: draft-ietf-cose-hash-envelope
> Title: COSE Hash Envelope
> Reviewer: Yaron Sheffer
> Review result: Has Nits
> 
> Overall the document is clear and mostly ready for publication.
> 
> - I suggest to add to the Terminology section a definition of "payload" and
> "preimage".

That should be addressed.

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

Yes, thank you, that has been fixed.

> 
> - 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.

The verifier's behavior does not differ from standard COSE, except for a 
possible optional additional step, now described in Section 5.3.

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

content-type is disallowed in favor of preimage-content-type, not 
forbidden altogether. Signers can still use preimage-content-type as 
they would content-type for a non-hashed payload, but verifiers benefit 
from the parameter being explicitly different.

When the actual content is a bstr, a verifier contemplating a 
content-type bstr might ask itself if that described the digest itself 
or the actual preimage. With preimage-content-type set to bstr, it is 
clear that the preimage itself was a bstr.

The text has been edited to add the example given in the paragraph above.

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

There are valid applications, such as transparency services/ledgers, 
which do not need to understand these header parameters to conduct 
meaningful authentication and registration.
The sentence only stated that Profiles are allowed to make these 
parameters critical, which is also possible without that sentence 
present... Hence, we removed it.

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

That sentence has been removed, too.

> 
> - 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.

We are also not sure if this is a valid use case and have clarified the 
scope of the document in Section 5.2.

Many thanks again for the review. Please let us know if further 
improvements are useful.

> 
> 
> _______________________________________________
> COSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]