I wasn't thinking about intentional modification. I was simply
wondering how is integrity of a binary blob ensured during transit
and storage.
After some further poking around, I think RFC 9404 answered all my questions. It shows how the binary blobId is generated from the blob content using one of the supported digest algorithms (like SHA1): https://datatracker.ietf.org/doc/html/rfc9404#section-4.2.1. It also mandates encoding the blob content in base64.
--Mohit
On 3/18/24 16:54, Bron Gondwana wrote:
On Mon, Mar 18, 2024, at 16:11, Mohit Sethi via Datatracker wrote:
One thing that I wondered while reading is how the integrity of the script blob
is ensured? How does the receiver verify the integrity of the binary script
content received?
I'm not sure the threat model you're worried about here.
The server gives a blobId for uploaded content and you use the ID. The server says that this blobId will give the same content if used later.
Either the server is trustworthy and it acts on the same content, or the server isn't trustworthy and ... then what's the difference? It could substitute anything no matter whether the data is uploaded concurrently or separately.
Bron.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
