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]
