jiebi/TextFlow huggingface dataset:
Original text:
Use of this algorithm can be indicated at runtime using the "ed25519" value for the "alg" signature parameter. <del> 3.3.6. </del>  If the signing algorithm is a JOSE signing algorithm from the JSON Web Signature and Encryption Algorithms Registry established by

Reviewer comments:
Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.

Revised text:
Use of this algorithm can be indicated at runtime using the "ed25519" value for the "alg" signature parameter.  <ins> 3.3.7. </ins> If the signing algorithm is a JOSE signing algorithm from the JSON Web Signature and Encryption Algorithms Registry established by
Original text:
credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be <del> present and covered as well as mandate a value for "context" that is specific to the API being protected. </del>  A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter

Reviewer comments:
Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.

Revised text:
credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be  <ins> present and covered as well as mandate a value for "tag" that is specific to the API being protected. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter
Original text:
"keyid": The identifier for the key material as a String value. <del> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify </del>  signatures relevant for specific applications or protocols. Additional parameters can be defined in the iana-param-contents.

Reviewer comments:
Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.

Revised text:
"keyid": The identifier for the key material as a String value.  <ins> "tag": An application-specific tag for the signature as a String value.  This value is used by applications to help identify </ins> signatures relevant for specific applications or protocols. Additional parameters can be defined in the iana-param-contents.
Original text:
Enforcing uniqueness of the "nonce" parameter. <del> Requiring an application-specific value for the "context" parameter. </del>  Application-specific requirements are expected and encouraged.  When an application defines additional requirements, it MUST enforce them

Reviewer comments:
Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.

Revised text:
Enforcing uniqueness of the "nonce" parameter.  <ins> Requiring an application-specific value for the "tag" parameter. </ins> Application-specific requirements are expected and encouraged.  When an application defines additional requirements, it MUST enforce them
Original text:
present, and applications should not put semantic meaning on the labels themselves.  Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached <del> to and covered by the signature.  In particular, the "context" parameter can be used to define an application-specific value as described in security-signature-context. </del>  7.2.6.

Reviewer comments:
Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.

Revised text:
present, and applications should not put semantic meaning on the labels themselves.  Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached  <ins> to and covered by the signature.  In particular, the "tag" parameter can be used to define an application-specific value as described in security-signature-tag. </ins> 7.2.6.
Original text:
either accepting or rejecting a message based on an unrelated or irrelevant signature.  In order to help an application select which signatures apply to its own processing, the application can declare a <del> specific value for the "context" signature parameter as defined in </del>  signature-params.  For example, a signature targeting an application <del> gateway could require "context="app-gateway"" as part of the signature parameters for that application. The use of the "context" parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted.  As a consequence, a verifier should only use value of the "context" parameter to limit which signatures to check.  Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in security-coverage. </del>  7.2.8.

Reviewer comments:
Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.

Revised text:
either accepting or rejecting a message based on an unrelated or irrelevant signature.  In order to help an application select which signatures apply to its own processing, the application can declare a  <ins> specific value for the "tag" signature parameter as defined in </ins> signature-params.  For example, a signature targeting an application  <ins> gateway could require "tag="app-gateway"" as part of the signature parameters for that application. The use of the "tag" parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted.  As a consequence, a verifier should only use value of the "tag" parameter to limit which signatures to check.  Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in security-coverage. </ins> 7.2.8.
Original text:
with a certificate, a client presents its X.509 certificate RFC5280 and proves possession of the corresponding private key to a server when negotiating a TLS connection or the resumption of such a <del> connection.  In contemporary versions of TLS RFC8446 RFC5246 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </del>  CertificateVerify and Finished messages. <del> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS </del>  1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate <del> authentication in HTTP/1.1 RFC7230 where the server decides whether </del>  to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
with a certificate, a client presents its X.509 certificate RFC5280 and proves possession of the corresponding private key to a server when negotiating a TLS connection or the resumption of such a  <ins> connection.  In contemporary versions of TLS TLS TLS1.2 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </ins> CertificateVerify and Finished messages.  <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS </ins> 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate  <ins> authentication in HTTP/1.1 RFC9112 where the server decides whether </ins> to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated
Original text:
The value of the header is encoded as described in encoding. The "Client-Cert" header field is only for use in HTTP requests and <del> MUST NOT be used in HTTP responses.  It is a single HTTP header field value as defined in Section 3.2 of RFC7230, which MUST NOT have a </del>  list of values or occur multiple times in a request. 2.3.

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
The value of the header is encoded as described in encoding. The "Client-Cert" header field is only for use in HTTP requests and  <ins> MUST NOT be used in HTTP responses.  It is a singleton header field value as defined in Section 5.5 of RFC9110, which MUST NOT have a </ins> list of values or occur multiple times in a request. 2.3.
Original text:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in RFC8446 or RFC5246, and </del>  validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection  <ins> with the client, such as is described in TLS or RFC5246, and </ins> validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following
Original text:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby <del> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </del>  When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled),

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby  <ins> presented by the client.  Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context.  Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals. </ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled),
Original text:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*".  3. 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using <del> HPACK RFC7541 or QPACK I-D.ietf-quic-qpack) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </del>  3.2.

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using  <ins> HPACK HPACK or QPACK QPACK) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. </ins> 3.2.
Original text:
allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. <del> HTTP/2 RFC7540 or HTTP/3 I-D.ietf-quic-http) should account for the additional size of header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </del>  3.3.

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g.  <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </ins> 3.3.
Original text:
5.1. Please register the following entries in the "Hypertext Transfer <del> Protocol (HTTP) Field Name Registry" defined by I-D.ietf-httpbis- semantics: </del>  Field name: Client-Cert

Reviewer comments:
update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204

Revised text:
5.1. Please register the following entries in the "Hypertext Transfer  <ins> Protocol (HTTP) Field Name Registry" defined by HTTP Semantics RFC9110: </ins> Field name: Client-Cert
Original text:
The QUERY method is subject to the same general security considerations as all HTTP methods as described in HTTP. <del> The QUERY method can be used as an alternative to passing query information in the query portion of a URI.  This is preferred in some cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </del>  6.

Reviewer comments:
briefly mentions security advantages See
Moved little changes into sec-: sensitive information can be in both and ; mention intermediaries.

Revised text:
The QUERY method is subject to the same general security considerations as all HTTP methods as described in HTTP.  <ins> The QUERY method can be used as an alternative to passing request information in the URI (e.g., in the query section).  This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.
Original text:
Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant <del> HTTP message content could require the Content-Digest header to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. </del>  A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter

Reviewer comments:
Adds a citation in 1.4 for DIGEST and forward links to the security considerations sections for covered component selection and message body coverage.
Minor issue noted while reviewing. -13 does give a good overview of message content considerations, and mentions Content-Digest along with a citation to the digest headers draft. However, the earliest mention of Content-Digest is in section 1.4, and there are several examples through the text that use it. Simple fixup is to cite digest in section 1.4 too, and forward ref to 7.2.8 so anyone interested in this knows where to jump to.

Revised text:
Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant  <ins> HTTP message content could require the Content-Digest header defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter