Size/length required: It was intended as a checksum and verification for DOS. You could argue it's only a DOS check if pulling from a remote location, which is optional, so making size/length optional seems prudent.
Use case: Documents (pdfs), sboms, contractual documents (pdf/docx), media (mp4, jpg, png), metadata (json), llms, etc. Being able to know how much space should be expected for pulling locally, knowing if it’s supposed to be a small <1mb size, but continues to stream beyond would be a means to stop and fail. Specs: The OCI Image spec has a descriptor, which includes mediatype, hash (digest), size and other optional data. The URL is based on the distribution spec protocol as the location can be redirected, while the "digest"/hash is a consistent ID, separating location from identification. -----Original Message----- From: [email protected] <[email protected]> Sent: Friday, March 7, 2025 9:54 AM To: cose <[email protected]> Subject: [COSE] Re: I-D Action: draft-ietf-cose-hash-envelope-02.txt On Fri, Mar 07, 2025 at 07:44:44AM -0600, Orie Steele wrote: > > On Fri, Mar 7, 2025, 6:03 AM Robin Bryce <[email protected]> wrote: > > > Hi Orie, > > > > > The client could retry, the client might not even need to resolve > > > the > > resource because of caching or having previously dereferenced the resource. > > > The resource could be compressed, have different transfer encoding, etc.. > > > > In the case where location is supplied the *reason* for that is (in > > the uses I'd anticipate) that the verifier is expected to fetch and > > hash the content from that location as part of verification. > > > > Which protocols require size to start the download? I am not aware of any (that do not require some manifest anyway). > Especially because of the factors you mention impacting > > Content-Length, I don't see how that verifier could know how many > > bytes to fetch ? What am I missing here ? > > > > The transfer protocol. > Last I checked, HTTP doesn't ask you how many bytes to download before > giving up, though I will admit I'm not an expert on every protocol > that might be used to resolve a file... Which is part of why I don't > want to comment on this in the draft. The issue is not that protocol needs to know file size. The issue is for example that the HTTP server sends 50GB file when it should send 50MB file. If the client tries to download that to storage, it might exhaust the storage. If the client tries to download that to memory, it will probably crash. > > > Given that location and content type are already optional, how can > > > you > > argue that lack of size makes the draft incomplete? > > > > Ok, the location being optional, and the size being mandatory does > > not make sense to me either. size being mandatory when location is > > supplied would make sense to me > > > > How come x5u doesn't have a length? With x5u, one could impose some pretty small size limits. For example, certificate chains >1MB should be extremely rare in wild. If the device is constrained, one could apply even lower limits. > How come every URL in a web page doesn't include the length of the > file that will be dereferenced? Most links are assumed to point to reasonably sized files. But loading too large files can absolutely crash browsers (even for text files, for other types there are DOM blowups as well). -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]
