Hi Ilari,
some comments/replies below. In general, it would be great if you could
provide some tangible change suggestions to help us avoid other readers
arriving at the same questions you arrived that. The editors are pretty
much in agreement that the current text mostly already does accomplish
that, but every kind of suggested change is very much welcome.
Viele Grüße,
Henk
[1] https://doi.org/10.6028/NIST.FIPS.204
On 16.08.24 08:37, Ilari Liusvaara wrote:
On Thu, Aug 15, 2024 at 03:55:33PM -0700, [email protected] wrote:
Internet-Draft draft-ietf-cose-hash-envelope-00.txt is now available. It is a
work item of the CBOR Object Signing and Encryption (COSE) WG of the IETF.
Title: COSE Hash Envelope
Authors: Orie Steele
Steve Lasker
Henk Birkholz
Name: draft-ietf-cose-hash-envelope-00.txt
Pages: 8
Dates: 2024-08-15
Some stuff:
- Should payload_hash_alg be required to be critical?
No. We should avoid rendering a header parameter to be critical, unless
it is absolutely clear why it is unavoidable.
- Assuming payload_hash_alg just causes content to be pre-hashed,
then how do payload_preimage_content_type and 'content type'
differ?
payload_preimage_content_type is about the original large content &
'content type' is about the hash that's the smaller digest. This "split"
is due to the conclusion that multi-suffix application layer
"media-type"/"content-format" will not help us here, I think.
- 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 am not sure I get the actual problem statement. As far as I think I
understand your comment, this seems to be an application layer topic.
- 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).
I think Orie already posted a reference to corresponding guidance
somewhere. FIPS 204 [1] includes text about hashing when signing large
content.
- What is output length of SHAKE256? 64 bytes (as usual)?
I do not know.
-Ilari
_______________________________________________
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]
