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

Related discussion:
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> <ins> specific value for the "tag" signature parameter as defined in </ins> 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> <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.
Code change:
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

Related discussion:
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> <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. <del> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS </del> <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 <del> authentication in HTTP/1.1 RFC7230 where the server decides whether </del> <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
Code change:
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

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

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

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

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

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

Related discussion:
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> <ins> Protocol (HTTP) Field Name Registry" defined by HTTP Semantics RFC9110: </ins> Field name: Client-Cert
Code change:
briefly mentions security advantages See
Moved little changes into sec-: sensitive information can be in both and ; mention intermediaries.

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

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

Related discussion:
text: The details of this kind of profiling are the purview of the application and outside the scope of this specification, however some <del> additional considerations are discussed in security. </del> <ins> additional considerations are discussed in security.  In particular, when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in security-coverage and security-message- content. </ins> 2.
Code change:
to
Currently, the references to HTTP semantics and to all HTTP versions are informative. While there are only two references to RFC9110, I find myself skeptical that someone would be able to implement it without knowing HTTP. We might consider making 9110 an normative reference, even if we think the individual pointers into it don't rise to that level.
You could normatively depend on the intermediary definitions in URL
Agreed about making HTTP semantics a normative reference.
Using and alining with 9110's intermediary definitions is likely worthwhile too. However, that's a larger effort that should maybe be considered separately?
I'm not too bothered about just changing labels between informative or normative. Thats easy to do and can be changed easily enough at later date. I think this draft actually does a good job of talking about the specialist case of a TTRP and we should keep that without too much meddling. But if the prose would benefit from shaking out a stronger sense of if implementations have normative requirements (directly or via references), I think this is a good ticket to track that against.
Thanks for the thoughts, Lucas. I'm inclined to not do much meddling.

Related discussion:
text: The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field <del> value as defined in Section 5.5 of RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </del> <ins> value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </ins> 2.3.
Code change:
and use "describes" rather than "standardize" to better align w/ the Informational intended status
As Yoda might say, do or do not. We can lose the aspiration here and be assertive about the document consensus progress.
I have a tendency towards that kind of demure writing. But you and Yoda are right. Will change.
LGTM, too.LGTM

Related discussion:
text: Abstract <del> This document defines HTTP extension header fields that allow a TLS </del> <ins> This document describes HTTP extension header fields that allow a TLS </ins> terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner.
Code change:
and use "describes" rather than "standardize" to better align w/ the Informational intended status
As Yoda might say, do or do not. We can lose the aspiration here and be assertive about the document consensus progress.
I have a tendency towards that kind of demure writing. But you and Yoda are right. Will change.
LGTM, too.LGTM

Related discussion:
text: commonly occurring functionality could improve and simplify interoperability between independent implementations. <del> This document aspires to standardize two HTTP header fields, "Client- Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client-Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic. While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the </del> <ins> This document describes two HTTP header fields, "Client-Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client- Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the </ins> certificate that was presented by the originating client in its connection to the TTRP.
Code change:
It might help to refer to the example in section 2.2 and/or 2.3.
Makes sense, can add a couple forward refs.

Related discussion:
text: value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. <ins> example-header in example has an example of the "Client-Cert" header field. </ins> 2.3. In the context of a TLS terminating reverse proxy deployment, the
Code change:
It might help to refer to the example in section 2.2 and/or 2.3.
Makes sense, can add a couple forward refs.

Related discussion:
text: purposes, it might be advantageous to split lists into multiple instances. <ins> example-chain-header in example has an example of the "Client-Cert- Chain" header field. </ins> 2.4. This section outlines the applicable processing rules for a TLS
Code change:
Intro para 3 has a chunk of text about fields not defined in this doc This could be condensed to say that the header fields in this document provide a standardized replacement for custom or proprietary fields that were known to be used prior to this document.
It is perhaps a bit long winded and admittedly not award winning literature. But I think it's useful context for the reader and prefer to keep it.
Right but in 20 years if the RFC says "a common practice today is using non-standard fields" it could read odd. Its clearer if this spec focuses on what it provides not what people came up with as custom solutions beforehand.
Thanks, looks good!

Related discussion:
text: application requirements.  In order for these types of application deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application <del> server.  A common way this information is conveyed in practice today is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </del> <ins> server.  At the time of writing, a common way this information is conveyed is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </ins> interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices respectively made (like what field names are used or are
Code change:
reword the header compression section with more consistent terms for the roles (to
LGTM modulo nit
This section talks about header compression and says Elsewhere in the document, you've used TTRP and Origin to identify the roles in play. I think it would be clearer to use them here. For instance, I might rewrite this as something like

Related discussion:
text: 3.1. <del> If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using 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. </del> <ins> If the connection between the TTRP and origin is capable of field compression (e.g., HPACK HPACK or QPACK QPACK), and the TTRP multiplexes more than one client's requests into that connection, the size and variation of "Client-Cert" and "Client-Cert-Chain" field values can reduce compression efficiency significantly.  An origin could mitigate the efficiency loss by increasing the size of the dynamic table.  If the TTRP determines that the origin dynamic table is not sufficiently large, it may find it beneficial to always send the field value as a literal, rather than entering it into the table. </ins> 3.2.