This is much better, thank you. I didn't catch that the Update Notification File contained all the Snapshot/Delta file hashes (making it like a manifest of sorts). Going back to read the draft now, I see that more clearly. Having a list of hashes in a signed file makes complete sense.
Thank you also for adding to the Security Considerations one of the risks associated with compression algorithms. The link to RFC 6713 (which then links back to RFC 1952- the GZIP RFC) helps for the other risks. Deb On Tue, Apr 14, 2026 at 2:28 PM Sasha Romijn <[email protected]> wrote: > Hello, > > Thank you for the review of our draft. > > On 13 Apr 2026, at 15:35, Deb Cooley via Datatracker <[email protected]> > wrote: > > > > > > Section 5.3, bullet 4, Section 5.4, bullets 6&8: Are these files > signed? And > > if so, does the client validate the signature? Or only the hash? Is > the hash > > algorithm the one that is specified in Section 6.4? > > > > Section 5.6: The mirror client only verifies the signature on the Update > > Notification File? Not on the Snapshot or the Delta files? > > > > Section 6.4: Consider mentioning that the jose registry referenced > specifies > > both the hash and signature algorithm. It might be useful to state that > the > > hash specified with the signature algorithm is the one that must be used. > > > > Section 7 and 8: I don't see anything about hashing the contents of > these > > files? Much less which hash to use (the one specified in Section 6.4). > > > > Section 11, para 3: Doing a bit for bit comparison of a hash is not an > > integrity check. Does the Delta and/or Snapshot happen before the Update > > Notification File? If so, then that has shows where an error/attack has > > occurred. > > Taking these comments together, the hash/signature model is: > > 1. The Update Notification File is signed with JWS. After retrieval, the > client verifies the signature against a preconfigured public key. This > proves integrity and authenticity of this file. > 2. All Delta/Snapshot files listed in the Update Notification File are > listed by filename and their SHA-256 hash. > 3. After downloading a Delta/Snapshot file, the client calculates the > file's hash locally, and verifies it matches the hash listed in the Update > Notification File. > > This prevents manipulation/substitution of a Delta/Snapshot file, as the > SHA-256 hash listed in the Update Notification File would no longer match > the content. The listed hash can not be manipulated either, as the Update > Notification File itself is signed with JWS. > > The draft wasn't making that as clear as it should, we've made > clarifications in: > > https://github.com/mxsasha/nrtmv4/commit/83c79040d7dfbc2dbcc4695d307991e84195cd48 > > > Section 11: There should be a short paragraph that explains the risks > > associated with compression algorithms. I can help write this > paragraph, if > > needed. > > I've added one in the same commit. If that does not address what you had > in mind, do let us know. > > Sasha
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
