[GROW] Re: Roman Danyliw's No Objection on draft-ietf-grow-nrtm-v4-09: (with COMMENT)

[Sasha Romijn <[e-mail]>]

Hello Roman,

Thank you for reviewing our draft. Responses inline:

On 14 Apr 2026, at 17:41, Roman Danyliw via Datatracker <[e-mail]> wrote
> ** Section 6.3
>   *  The hash attribute in snapshot and delta elements MUST be the
>      hexadecimal encoding of the SHA-256 hash [SHS] of the referenced
>      file.  The mirror client MUST verify this hash when the file is
>      retrieved and reject the file if the hash does not match.
> 
> This document is hard-coding SHA-256.  What is the proposed approach for
> algorithm agility?

The SHA-256 hash is intentionally fixed. The hash is security-relevant, as substitution of a different file that matches the hash in the signed Update Notification File would be problematic. However, to the best of my knowledge, SHA-256's resistance to this is not under any credible threat. Adding hash algorithm flexibility would introduce significant extra complexity (additional fields, negotiation, migration) that we don't feel is justified at this time.

> ** Section 6.4
>   *  Implementations MUST support ES256 for interoperability.  The
>      algorithm MUST NOT be Deprecated
> 
> Consider if it worth emphasizing (since RFC9864 needed to clarify) that “The
> selected algorithm MUST NOT be marked as Deprecated or _Prohibited_”? (i.e.,
> add text about “Prohibited”).

Yes, we adopted this. This section was also mentioned in other reviews, and we have made additional refinements in:
https://github.com/mxsasha/nrtmv4/commit/a4b1105e48247ce6a64bcbc2b8ecd570b0810e55

Sasha