> What happens if the resolved file has the correct hash, but incorrect file > size? > Fail transfer as soon as incorrect size is received (as soon as HTTP Content-Length is received, when file cuts off prematurely, or file continues past where it should end). I'd agree fail is the expected outcome, if the actual length is either too small or too big.
> Is the file name important? I’d suggest it's not "important", and if it was, be incorporated into the location value. Beyond location, I’d suggest it’s beyond the scope of this draft. Scope I believe we’re all focused on keeping the scope minimal, engaging other specs where needed, which can add other header values to an envelope. We’re not trying to make a package manager, rather provide the minimal required properties to make hash-envelope useful. Since a complete scenario would involve downloading the content, confirming the hash matches, and knowing the size/length would mitigate DOS attacks, I do believe it meets the bar for scope, or the draft could be argued as incomplete. 122 Meeting I requested time from the chairs to discuss in the COSE meeting on Wednesday Steve -----Original Message----- From: Henk Birkholz <[email protected]> Sent: Wednesday, March 5, 2025 2:28 AM To: Orie Steele <[email protected]>; Carsten Bormann <[email protected]> Cc: Steve Lasker <[email protected]>; Ilari Liusvaara <[email protected]>; cose <[email protected]> Subject: Re: [COSE] Re: I-D Action: draft-ietf-cose-hash-envelope-02.txt Hi Orie, in summary what I read is: * this is exiting but does not belong here * adding hash-env-sigs to existing systems The question is, how much "convenience information" belongs in an "un-profiled" cose hash envelope for existing systems, right? Pointing to an instance of the pre-image is already an option. Indicating the intended size of the pre-image seems to be very close, semantically. So the question is about scope creep vs. simplicity of resulting RFC. Yes? We added the "length" (are we settled on the name? length? ...) due to Ilari's feedback. If I want to convey metadata about a pre-image, there is already RFC9393. In consequence, I am leaning very so slightly to Orie's point and "keeping it simple". I acknowledge the intended use for that size... sorry length value, but I am not sure that this is the right place (aka the right I-D) to address it. Are there any other strong proponents for an optional pre-image "length" header parameter? If not, maybe we can come to an in-room decision at IETF 122 meeting and not include it. Viele Grüße, Henk On 05.03.25 03:49, Orie Steele wrote: > Hi, > > I'm hesitant to start considering file transfer in scope for this draft. > > The original motivation was to create a simple standard syntax for > signing hashes that are already used as identifiers, such as sha256 of > spdx sbom, or container hashes... > Delivery and integration for these is already a solved problem. > > We now seem to be imagining using hash envelope as part of some > verifiable build system, that uses the optional location, content type, > and a new file size parameter, to resolve large binaries from small > signatures and verifiable metadata. > > That's exciting. > > I'd been imagining adding hash envelope signatures to existing systems, > not using it to build new artifact repositories or package management > systems. > > At a certain point, it's probably better to sign a corim manifest (which > as you can see also includes hashes)... And let the manifest carry the > information necessary to download data. > > That's all exciting stuff, but I prefer to not include it in this draft. > > Simplicity is what makes successful standards. > > I'm not opposed to profiling hash envelope to build a package manager, > especially one that works well in constrained environments, I would just > prefer address those requirements in a dedicated document. > > Regards, > > OS > > On Tue, Mar 4, 2025, 10:55 AM Carsten Bormann <[email protected] > <mailto:[email protected]>> wrote: > > Hi Orie, > > > What happens if the resolved file has the correct hash, but > incorrect file size? > > You invoke crypto agility and choose a better hash function :-) > (I understand Ilari’s argument that being able to limit the file > size before computing the hash can help mitigate DoS.) > > > I wonder if there is some CBOR related filesystem RFC that could > provide the file size and other relevant metadata. > > file-entry = { > filesystem-item, > ? size => uint, > ? file-version => text, > ? hash => hash-entry, > * $$file-extension, > global-attributes, > } > > Not an RFC yet, but pretty advanced already: > > https://www.ietf.org/archive/id/draft-ietf-rats-corim-07.html#appendix-A-1 > <https://www.ietf.org/archive/id/draft-ietf-rats-corim-07.html#appendix-A-1> > > Grüße, Carsten > > > _______________________________________________ > 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]
