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]

Reply via email to