-00 feedback from ilari

[OR13]

https://mailarchive.ietf.org/arch/msg/cose/PCJQ7S7IMnZLWxjI677Wv-qeLaI/

[SteveLasker]

Does https://github.com/cose-wg/draft-ietf-cose-hash-envelope/pull/23/files#diff-d760cfc872ca7eedc40666f385a0b41d3a8dbce96529e59fd0fc6ef3f58921f5R139-R140 address the feedback?

[OR13]

No

- Should payload_hash_alg be required to be critical?

We should write some text providing guidance for this... IMO better to say it MAY be marked critical.

- Assuming payload_hash_alg just causes content to be pre-hashed,
  then how do payload_preimage_content_type and 'content type'
  differ?

I think this one is addressed.

- Maybe add protected header for preimage length. So that applications
  don't have to deal with over-large responses from HTTP servers (which
  could cause problems).

  Something like:

  &(payload_preimage_content_length: TBD_4) => uint

  If payload_hash_alg just causes prehashing, maybe call it
  'content length' or something.

I don't understand this comment, we should get clarity on the list.

- Picking the same hash function as the signature does not guarantee
 equal strength, because some signatures have internal collision
 mitigations (e.g., EdDSA, ML-DSA and SLH-DSA).

This is missing the point of the original text, which just says "align" as in... dont use sha1 with P521... I tried to eleaborate on this with the ES384 example

[OR13]

This comment is relevant: https://mailarchive.ietf.org/arch/msg/cose/JonuJfnRwpR7wlmZ40Vyt-uuwoY/