jiebi/CodeConvo huggingface dataset:
Code change:
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)

Related discussion:
text: the IANA Hash Algorithms for HTTP Digest Fields registry; see establish-hash-algorithm-registry. <del> The "standard" algorithms listed in this document are suitable for many purposes, including adversarial situations where hash functions might need to provide resistance to collision, first-preimage and second-preimage attacks.  Algorithms listed as "insecure" either provide none of these properties, or are known to be weak (see NO-MD5 and NO-SHA). For adversarial situations, which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  As there is no negotiation, endpoints that depend on a digest for security will be vulnerable to attacks on the weakest algorithm they are willing to accept. </del> Transition from weak algorithms is supported by negotiation of hashing algorithm using "Want-Content-Digest" or "Want-Repr-Digest" (see want-fields) or by sending multiple digests from which the
Code change:
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)

Related discussion:
text: While algorithm agility allows the migration to stronger algorithms it does not prevent the use of weaker algorithms.  Integrity fields <del> do not provide any mitigiations for downgrade or substitution attacks </del> <ins> do not provide any mitigations for downgrade or substitution attacks </ins> (see Section 1 of RFC6211) of the hashing algorithm.  To protect against such attacks, endpoints could restrict their set of supported algorithms to stronger ones and protect the fields value by using TLS
Code change:
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)

Related discussion:
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> <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. <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> <ins> [1] https://www.iana.org/assignments/http-digest-hash-alg/ </ins>
Code change:
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.

Related discussion:
text: insensitive components such as field names, request URI scheme, or host. <del> Addition or removal of leading or trailing whitespace to a field value. Addition or removal of "obs-fold" from field values. </del> Changes to the request target and authority that when applied together do not result in a change to the message's target URI, as defined in HTTP. <ins> Additionally, there are some transformations that are either deprecated or otherwise not allowed, but still could occur in the wild.  These transformations can still be handled without breaking the signature, and include things such as: Use, addition, or removal of leading or trailing whitespace in a field value. Use, addition, or removal of "obs-fold" in field values (HTTP1). </ins> We can identify these types of transformations as ones that should not prevent signature verification, even when performed on message components covered by the signature.  Additionally, all changes to
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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.
Code change:
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

Related discussion:
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
Code change:
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?

Related discussion:
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> <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.
Code change:
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?

Related discussion:
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> <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
Code change:
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?

Related discussion:
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> <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
Code change:
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?

Related discussion:
text: This would result in the following unsigned response message: <ins> The server signs the response with its own key, including the "@status" code and several header fields in the covered components. </ins> To cryptographically link the response to the request, the server <del> signs the response with its own key and includes the method, authority, and the signature value "sig1" from the request in the covered components of the response.  The signature base for this example is: </del> <ins> includes the method, authority, and the signature and signature input labeled "sig1" from the request in the covered components of the response.  The signature base for this example is: </ins> The signed response message is: <del> Since the request's signature value itself is not repeated in the response, the requester MUST keep the original signature value around long enough to validate the signature of the response that uses this component identifier. </del> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. <ins> Since the signature component values from the request are not repeated in the response, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier.  In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application. Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values as the client would not be able to validate the resulting signature. Applications needing this type of binding have to sign sufficient portion the request to ensure that it is uniquely tied to the response.  Signing the signature value of a signed request alone does not provide sufficient coverage in most cases, as discussed in security-sign-signature. The response signature can only cover what is included in the request.  Therefore, if an application needs to bind the message content of the request in its response, the client needs to include a means for covering that content, such as a Content-Digest field.  See the discussion in security-message-content for more information. </ins> The "req" parameter MUST NOT be used in a signature that targets a request message.
Code change:
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?

Related discussion:
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
Code change:
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?

Related discussion:
text: information in its signature context to account for the change in authority, this practice requires additional configuration and extra care (see further discussion in security-context-multiple- <del> signatures).  To counter this, the proxy adds its own signature over the new message before passing it along.  The proxy includes the new "@authority" derived component and the Forwarded header, which it added to the message.  The proxy's signature also includes the client's signature value from the original message in its covered components, as a dictionary field member under the label "sig1". Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </del> <ins> signatures).  The proxy is in a position to make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.  The proxy includes the new "@authority" derived component and the Forwarded header, which the proxy has added to the message.  The proxy also includes elements from the original message that are relevant to the origin server's processing, such as the "@method", "@path", and "@query" in this example, even if those components were covered by the original signature.  The proxy additionally includes the client's signature value and signature input from the original message in the new signature's covered components.  In our example application, this is used as a way for the proxy to indicate to the origin server that the proxy has read and verified these values in their original context. While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The origin server also has assurance that the message has been forwarded intact from the trusted proxy. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </ins> And a signature output value of:
Code change:
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?

Related discussion:
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