Hi, I understand there is a desire to add the file size (in octets) to the protected header, and to register a new header parameter.
The existing header parameters are hints for resolving the file (location and content type). This file size parameter, is file metadata, and is partly redundant to the file hash, since the hash is commiting to the exact file bytes. Having a file size enables a party with a hash envelope to decide if the size is too large to even attempt to use the location and content type. Is the file name important? What happens if the resolved file has the correct hash, but incorrect file size? Design wise, I've always wanted to minimize the number of header parameter registration associated with this draft. I wonder if there is some CBOR related filesystem RFC that could provide the file size and other relevant metadata. The request to add more file specific metadata to the header makes sense to me. It enables verifiers to develop more fine grained policies regarding processing of files that have an associated hash envelope. I would just want to make sure we explored this use case a bit more, before assuming that a single new header parameter for file size is the correct solution. Regards, OS (as just one of the authors) On Mon, Mar 3, 2025, 1:59 PM Steve Lasker <[email protected]> wrote: > Thanks, Ilari, > > > - There should be (protected) parameter to store preimage length to > assist in safely fetching the payload. > Thank you. We've added: > https://github.com/cose-wg/draft-ietf-cose-hash-envelope/pull/46 > > I defer to Henk and Orie for the history related to LAMPS and COSE > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Wednesday, February 26, 2025 12:30 AM > To: [email protected] > Subject: [COSE] Re: I-D Action: draft-ietf-cose-hash-envelope-02.txt > > On Tue, Feb 25, 2025 at 08:05:50PM +0000, Steve Lasker wrote: > > 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. > > Ugh. RFC 9052 does not even seem to recommend protecting content-type. > > > > - 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. > > Payload_location does not affect message processing, whereas content_type > does. > > > > - There should be (protected) parameter to store preimage length to > assist in safely fetching the payload. > > > Are you suggesting we add another size header? > > Yes. Obviously it should be protected, and messages that have it also > should have payload_location. > > > > - 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. > > I see two ways of using hash envelopes: > > 1) Standing in for some very large file that is available from somewhere > else. The payload is attached and payload_location is presumably set. > > In this case, after verifying the signature, the application is supposed > to fetch the payload and use the attached hash to verify its integerity. > > This mode has been presented as motivation for hash envelopes in various > presentations. > > 2) To sign large detached payloads without using pre-hash signatures. The > payload is detached and there is no payload_location. > > In this case, the detached payload supplied by application needs to be > hashed and used as payload in signature verification (if there already is > attached payload, it obviously must match, or the signature is going to > fail anyway). > > I don't offhand remember if this mode has been in any presentations. > > > The latter is about transparently handling the second case. > > > > - 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. > > What should an application do with COSE_Encrypt message that contains > payload_hash_alg? > > > > - 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. > > Pre-hash signatures have inherit problems. The second use of hash > envelopes above is to avoid using signature pre-hashing. > > LAMPS WG had an extensive discussion about HashML-DSA, and concluded that > it is more trouble than it is worth, even for CMS, where payloads can be > large (the "Two-Party Signing" is solved by using external mu). > > > > > -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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
