jiebi/TextFlow huggingface dataset:
Original text:
7.2. <del> This memo sets this specification to be the establishing document for the Hash Algorithms for HTTP Digest Fields [2] registry defined in </del>  algorithms. <del> IANA is asked to initialize the registry with the entries in iana- hash-algorithm-table. </del> 8.  References 8.1.  URIs <del> [1] https://www.iana.org/assignments/http-dig-alg/ [2] https://www.iana.org/assignments/http-structured-dig-alg/ </del> 

Reviewer comments:
Murray suggested some things that we could change about the way new IANA registry was being handled. This change: tries to make it clearer that this document uses a new registry that we will need IANA to create moves rote IANA instructions to the IANA considerations better highlights interesting hash algorithm considerations for implmenters clarifies the registration procedure and expands on the expectations for the Designated Expert(s)

Revised text:
7.2.  <ins> IANA is requested to create the new "Hash Algorithms for HTTP Digest Fields" registry at https://www.iana.org/assignments/http-digest- hash-alg/ [1] and populate it with the entries in iana-hash- algorithm-table.  The procedure for new registrations is provided in </ins> algorithms.  8.  References 8.1.  URIs  <ins> [1] https://www.iana.org/assignments/http-digest-hash-alg/ </ins>
Original text:
Some examples of these kinds of transformations, and the effect they have on the message signature, are found in example-transform.  1.4. HTTP Message Signatures are designed to be a general-purpose security

Reviewer comments:
Add reference for obs-fold, add note about transforms,
The spec several times refers to the term obs-fold, but doesn't say where it's defined (-> URL). Furthermore, in 1.3 it claims that addition of obs-fold could be permitted under certain circumstances. That IMHO is incorrect.
Adding the reference makes sense. The signatures spec doesn't change how the messages are created, nor does it make more allowed than it is now, it just tells people what to do with the messages that they have even if they have in them.
: This is misleading. No HTTP permits addition of leading/trailing whitespace. Leading/trailing whitespace in field values by definition is invalid.
While technically true, many (including implementers) won't understand the nuance Here. Given the impact, it's better to be over-inclusive, I think.
If invalid changes are included, then it might be best to either say that some of these changes might be invalid or point specifically to those that are.
Yes, my proposal would be to split the list into two; the second just listing the transformatios that might happen in reality despite bing forbidden.
NAME I agree that we need to prepare developers for the messy reality of HTTP in addition to what's strictly allowed. What else would appear in this second list?
The only other thing that I can see right now is addition of obs-fold.
Speaking of which: there are other transformations like parsing and re-serializing field values, which are certainly allowed. Shouldn't these be mentioned here as well?
NAME Re-serialization of a field value by an intermediary would likely break things in an expected way. It was my impression that this was not allowed by intermediaries in general. A structured field does help this, and the flag protects against that kind of transformation, as mentioned in the section.
I don't think we have a rule anywhere that would keep an intermediary from parsing and re-serializing fields. And even if that was the case, the same would be true for the original point (addition of leading/trailing WS), so I'm trying to understand where we draw the line.

Revised text:
Some examples of these kinds of transformations, and the effect they have on the message signature, are found in example-transform. <ins> Other transformations, such as parsing and re-serializing the field values of a covered component or changing the value of a derived component, can cause a signature to no longer validate against a target message.  Applications of this specification need to take care to ensure that the transformations expected by the application are adequately handled by the choice of covered components. </ins> 1.4. HTTP Message Signatures are designed to be a general-purpose security
Original text:
Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in HTTP1.  Note that this <del> behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification which do not allow internal line folding. </del>  Concatenate the list of values together with a single comma (",") and a single space (" ") between each item.

Reviewer comments:
Add reference for obs-fold, add note about transforms,
The spec several times refers to the term obs-fold, but doesn't say where it's defined (-> URL). Furthermore, in 1.3 it claims that addition of obs-fold could be permitted under certain circumstances. That IMHO is incorrect.
Adding the reference makes sense. The signatures spec doesn't change how the messages are created, nor does it make more allowed than it is now, it just tells people what to do with the messages that they have even if they have in them.
: This is misleading. No HTTP permits addition of leading/trailing whitespace. Leading/trailing whitespace in field values by definition is invalid.
While technically true, many (including implementers) won't understand the nuance Here. Given the impact, it's better to be over-inclusive, I think.
If invalid changes are included, then it might be best to either say that some of these changes might be invalid or point specifically to those that are.
Yes, my proposal would be to split the list into two; the second just listing the transformatios that might happen in reality despite bing forbidden.
NAME I agree that we need to prepare developers for the messy reality of HTTP in addition to what's strictly allowed. What else would appear in this second list?
The only other thing that I can see right now is addition of obs-fold.
Speaking of which: there are other transformations like parsing and re-serializing field values, which are certainly allowed. Shouldn't these be mentioned here as well?
NAME Re-serialization of a field value by an intermediary would likely break things in an expected way. It was my impression that this was not allowed by intermediaries in general. A structured field does help this, and the flag protects against that kind of transformation, as mentioned in the section.
I don't think we have a rule anywhere that would keep an intermediary from parsing and re-serializing fields. And even if that was the case, the same would be true for the original point (addition of leading/trailing WS), so I'm trying to understand where we draw the line.

Revised text:
Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in HTTP1.  Note that this  <ins> behavior is specific to HTTP/1.1 and does not apply to other versions of the HTTP specification which do not allow internal line folding. </ins> Concatenate the list of values together with a single comma (",") and a single space (" ") between each item.
Original text:
use the connection established through the proxy, but need to gracefully handle situations in which this parameter is not present.  3. The "next-hop-aliases" parameter does not include any DNSSEC

Reviewer comments:
Since next-hop-aliases is a String parameter, the syntax allows an empty string . In cases where there is no chain, is it advisable to send the empty string to indicate this, rather than omitting the parameter? If so, it might help to add a sentence somewhere that highlights this usage type.
That's a good question! I don't think there needs to be a normative requirement here, but I think it's reasonable to have signify that there were no aliases.
This mention is clear. LGTM

Revised text:
use the connection established through the proxy, but need to gracefully handle situations in which this parameter is not present. <ins> The proxy MAY send the empty string ("") as the value of "next-hop- aliases" to indicate that no CNAME records were encountered when resolving the next hop's name. </ins> 3. The "next-hop-aliases" parameter does not include any DNSSEC
Original text:
material, or use some pre-configured algorithm agreed upon by the signer and verifier. <del> A means of determining that a given key and algorithm presented in the request are appropriate for the request being made.  For </del>  example, a server expecting only ECDSA signatures should know to reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
material, or use some pre-configured algorithm agreed upon by the signer and verifier.  <ins> A means of determining that a given key and algorithm used for a signature are appropriate for the context of the message.  For </ins> example, a server expecting only ECDSA signatures should know to reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.
Original text:
Within a single list of covered components, each component identifier MUST occur only once.  One component identifier is distinct from <del> another if either the component name or its parameters differ. Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct.  The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality.  That is to say, ""foo";bar;baz" cannot be in the same message as ""foo";baz;bar", since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form. </del>  The component value associated with a component identifier is defined by the identifier itself.  Component values MUST NOT contain newline

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
Within a single list of covered components, each component identifier MUST occur only once.  One component identifier is distinct from  <ins> another if the component name differs, or if any of the parameters differ for the same component name.  Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct, such as ""foo";bar" and ""foo";baz".  The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality checks.  That is to say, ""foo";bar;baz" cannot be in the same message as ""foo";baz;bar", since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form. </ins> The component value associated with a component identifier is defined by the identifier itself.  Component values MUST NOT contain newline
Original text:
allowed to combine values of HTTP fields with any amount of whitespace between the commas, and if this behavior is not accounted for by the verifier, the signature can fail since the signer and <del> verifier will be see a different component value in their respective </del>  signature bases.  For robustness, it is RECOMMENDED that signed messages include only a single instance of any field covered under the signature, particularly with the value for any list-based fields

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
allowed to combine values of HTTP fields with any amount of whitespace between the commas, and if this behavior is not accounted for by the verifier, the signature can fail since the signer and  <ins> verifier will see a different component value in their respective </ins> signature bases.  For robustness, it is RECOMMENDED that signed messages include only a single instance of any field covered under the signature, particularly with the value for any list-based fields
Original text:
For each message component item in the covered components set (in order):  Append the component identifier for the covered component serialized according to the "component-identifier" ABNF rule. Note that this serialization places the component name in

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
For each message component item in the covered components set (in order): <ins> Check that the component identifier (including its parameters) has not already been added to the signature base.  If this happens, produce an error. </ins> Append the component identifier for the covered component serialized according to the "component-identifier" ABNF rule. Note that this serialization places the component name in
Original text:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. <del> The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application.  Since the proxy's signature covers the client signature, the backend service fronted by the proxy can trust that the proxy has validated the incoming signature. </del> 5. While a signer is free to attach a signature to a request or response

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm.  5. While a signer is free to attach a signature to a request or response
Original text:
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple.  7.3. 7.3.1.

Reviewer comments:
A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?

Revised text:
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple. <ins> Applications that make use of content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header field in the request, the server is unable to include a signature that covers the request's content. </ins> 7.3. 7.3.1.
Original text:
algorithm-table.  The procedure for new registrations is provided in algorithms.  8.  References 8.1.  URIs [1] https://www.iana.org/assignments/http-digest-hash-alg/ 

Reviewer comments:
[ ] to obsolete the IANA Digest Algorithms Registry or define another registry [ ] it can stay as historical ~identify whether and how it should stay~ [x] if it should stay, the note below should be fixed.
I think it's easiest to just add a request to update the note in the IANA considerations of digest spec. E.g. current: something like
cc: NAME guidance welcome
Note: this has been fixed. the IANA Digest Algorithm Registry Note not to mention "message body" since it's not even mentioned in RFC3230.
NAME NAME what is expected to happen to URL after Digest's deprecation? Can it be marked as "historical" to avoid issues with current Digest implementers?
Yes, IANA can be instructed to do that in IANA Considerations.

Revised text:
algorithm-table.  The procedure for new registrations is provided in algorithms. <ins> 7.3. IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2]. </ins> 8.  References 8.1.  URIs [1] https://www.iana.org/assignments/http-digest-hash-alg/ <ins> [2] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml </ins>
Original text:
exporter is used to generate a 32-byte key which is then used as a nonce.  3. The "Unprompted-Authentication" header field allows a user agent to

Reviewer comments:
Add requirement for unprompted auth to use TLS 1.2 with extended master secret or later. Fixes httpwg/http-extensions
Please mark this PR as fixing the corresponding issue
From Ilari Liusvaara on the :

Revised text:
exporter is used to generate a 32-byte key which is then used as a nonce. <ins> Because the TLS keying material exporter is only secure for authentication when it is uniquely bound to the TLS session RFC7627, the Signature and HMAC authentication schemes require either one of the following properties: The TLS version in use is greater or equal to 1.3 TLS. The TLS version in use is greater or equal to 1.2 and the Extended Master Secret extension RFC7627 has been negotiated. Clients MUST NOT use the Signature and HMAC authentication schemes on connections that do not meet one of the two properties above.  If a server receives a request that uses these authentication schemes on a connection that meets neither of the above properties, the server MUST treat the request as malformed. </ins> 3. The "Unprompted-Authentication" header field allows a user agent to
Original text:
the corresponding key, so binding authentication to requests would not provide much benefit in practice.  8. 8.1.

Reviewer comments:
Fixes httpwg/http-extensions.
Please mark this PR as fixing the corresponding issue
From NAME on the :
The conservative thing to do here would be to insist that the key be unique to the protocol. We have domain separation in our outputs, so we don't need to worry about unprompted auth messages being used in cross-protocol attacks, but a different protocol (that doesn't use context strings) could possibly be induced to generate unprompted auth messages. We also need to worry about key compromise. Imagine a protocol that leaks the private / secret key, that shares a key with unprompted auth. This doesn't even need to be a bug, it could be a commit-before-reveal style protocol. (Obviously that's a pathological example, but it shows we can't assume composability with all protocols) If we want to do a formal analysis (which I do) I think we need to be conservative here.
SGTM

Revised text:
the corresponding key, so binding authentication to requests would not provide much benefit in practice. <ins> Key material used for authentication in unprompted authentication, whether symmetric or asymmetric MUST NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. </ins> 8. 8.1.
Original text:
mechanism QUIC-TLS. The user agent leverages a TLS keying material exporter KEY-EXPORT to <del> generate a nonce which can be signed using the user's key.  The </del>  keying material exporter uses a label that starts with the characters "EXPORTER-HTTP-Unprompted-Authentication-" (see schemes for the labels and contexts used by each scheme).  The TLS keying material

Reviewer comments:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Revised text:
mechanism QUIC-TLS. The user agent leverages a TLS keying material exporter KEY-EXPORT to  <ins> generate a nonce which can be signed using the chosen key.  The </ins> keying material exporter uses a label that starts with the characters "EXPORTER-HTTP-Unprompted-Authentication-" (see schemes for the labels and contexts used by each scheme).  The TLS keying material
Original text:
4.1. <del> The OPTIONAL "u" (user ID) parameter is a byte sequence that specifies the user ID that the user agent wishes to authenticate. </del>  4.2. The OPTIONAL "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the <del> credential that matches its user ID. </del>  4.3.

Reviewer comments:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Revised text:
4.1.  <ins> The OPTIONAL "k" (key ID) parameter is a byte sequence that identifies which key the user agent wishes to use to authenticate. This can for example be used to point to an entry into a server-side database of known keys. </ins> 4.2. The OPTIONAL "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the  <ins> credential that matches its key ID. </ins> 4.3.
Original text:
7. <del> Unprompted Authentication allows a user-agent to authenticate to an </del>  origin server while guaranteeing freshness and without the need for the server to transmit a nonce to the user agent.  This allows the server to accept authenticated clients without revealing that it

Reviewer comments:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Revised text:
7.  <ins> Unprompted Authentication allows a user agent to authenticate to an </ins> origin server while guaranteeing freshness and without the need for the server to transmit a nonce to the user agent.  This allows the server to accept authenticated clients without revealing that it