Hi, Ilari, thanks for the feedback. We discussed in meeting today, incorporating several changes https://github.com/cose-wg/draft-ietf-cose-hash-envelope/pull/45, and provided some answers below. Please let us know if you have any more feedback. Steve
-----Original Message----- From: [email protected] <[email protected]> Sent: Friday, February 21, 2025 11:22 AM To: [email protected] Subject: [COSE] Re: I-D Action: draft-ietf-cose-hash-envelope-02.txt 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. > As content_type is listed in generic headers, within RFC9052, we want to be consistent, and don't intend to make changes. - Why payload-location has to be protected? That does not seem so critical. The payload will be integerity-checked anyway. > The authors and editor discussed and decided the payload_location should be treated the same as pre-image-content-type. We would like to add instructions for processing the pre-image-content-type and location, regardless of where they are present. - There should be (protected) parameter to store preimage length to assist in safely fetching the payload. > Are you suggesting we add another size header? - Payload-location SHOULD NOT be present in hash-envelope messages with detached payload. > Detached payloads are part of RFC9052, we discussed and disagree we should make any additional statement in this draft. - 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. > This draft doesn't propose changing the semantics of cosesign_1. CoseSign1 supports attached and detached payloads. - The payload_hash_alg is required in prose, but marked as optional in the CDDL for Hash_Envelope_Protected_Header. > Thanks, good catch, the question mark is removed in PR# 45 - 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. > PR #45 moves Encrypted Hashes into the 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. > CoseSign1 secures the entire signature1 structure. We believe this is acceptable, even in the presence of pre-hash signature algorithms that might be registered in the future. - 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). > You're correct. We were asked to add, reluctantly added, but we'll remove mentions Ed25519ph and HashML-DSA. COSE Algorithms for Two-Party Signing (https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-00.html) has more info if desired. -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]
