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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
