On Fri, Feb 21, 2025 at 09:40:22AM -0800, [email protected] wrote: > Internet-Draft draft-ietf-cose-hash-envelope-02.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-02.txt > Pages: 11 > Dates: 2025-02-21
Some comments from looking through the diff (some are repeats): - Why preimage content type may be unprotected? That seems like attack vector to me. - Why payload-location has to be protected? That does not seem so critical. The payload will be integerity-checked anyway. - There should be (protected) parameter to store preimage length to assist in safely fetching the payload. - Payload-location SHOULD NOT be present in hash-envelope messages with detached payload. - If application supplies detached payload, signature verification SHOULD apply the indicated hash algorithm to it. If the result does not match included payload, the signature MUST be rejected, otherwise the result is used as payload in signature verification. - The payload_hash_alg is required in prose, but marked as optional in the CDDL for Hash_Envelope_Protected_Header. - The draft mentions COSE_Encrypt. What do these paremeters mean in context of COSE_Encrypt? And the whole section looks like something that should be subsection of Security Considerations. - The security considerations mention pre-hashed signature algorithms. This mechanism SHOULD NOT be used with pre-hashed signatures (unless the algorithm is inherently pre-hashed, e.g., ECDSA), and SHOULD instead be used as alternative to pre-hashing. - The draft mentions Ed25519ph, which is not supported in COSE at all, and HashML-DSA, which is inherently problematic to support in COSE (the current plan for ML-DSA in COSE assumes that HashML-DSA is NOT supported). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
