-00 feedback from ilari

OR13 commented 1 month ago

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

SteveLasker commented 1 month ago

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

OR13 commented 3 weeks ago

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 commented 2 weeks ago

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

cose-wg / draft-ietf-cose-hash-envelope

-00 feedback from ilari #22