jiebi/CodeConvo huggingface dataset:
Code change:
Spotted another mention of accidental while I was at it, so changed that too.
From NAME WGLC review: Corruption could also be non-accidental. Let's remove the accidental qualifier or add words about explicit manipulation (for good or bad purposes).
Agree, but I think that accidental/bad implementation has to be mentioned. See URL iirc there were some comments regarding the fact that Digest alone (eg. without other mechanisms) is not enough to protect against malicious agents... NAME do you remember anything on that? The current text imho is correct, since it adds:
NAME NAME I'd close with no-action :)
NAME Removing "accidental" from the sentence in question would fix the issue.
I completely agree, I'll do that!
LGTM

Related discussion:
text: character sets used for the encoding. Insecure digest algorithms MAY be used to preserve integrity against <del> accidental change, but MUST NOT be used in a potentially adversarial </del> <ins> corruption, but MUST NOT be used in a potentially adversarial </ins> setting; for example, when signing the digest of content for authenticity.
Code change:
Spotted another mention of accidental while I was at it, so changed that too.
From NAME WGLC review: Corruption could also be non-accidental. Let's remove the accidental qualifier or add words about explicit manipulation (for good or bad purposes).
Agree, but I think that accidental/bad implementation has to be mentioned. See URL iirc there were some comments regarding the fact that Digest alone (eg. without other mechanisms) is not enough to protect against malicious agents... NAME do you remember anything on that? The current text imho is correct, since it adds:
NAME NAME I'd close with no-action :)
NAME Removing "accidental" from the sentence in question would fix the issue.
I completely agree, I'll do that!
LGTM

Related discussion:
text: This document specifies a data integrity mechanism that protects HTTP "representation data" or content, but not HTTP header and trailer <del> fields, from certain kinds of accidental corruption. </del> <ins> fields, from certain kinds of corruption. </ins> Digest fields are not intended to be a general protection against malicious tampering with HTTP messages.  This can be achieved by
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: sha-512 Description: The SHA-512 algorithm RFC6234.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648. </del> <ins> algorithm is encoded using base64 RFC4648. </ins> Reference: RFC6234, RFC4648, this document.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: sha-256 Description: The SHA-256 algorithm RFC6234.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648. </del> <ins> algorithm is encoded using base64 RFC4648. </ins> Reference: RFC6234, RFC4648, this document.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: md5 <del> Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del> <ins> Description: The MD5 algorithm RFC1321.  The output of this algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: sha Description: The SHA-1 algorithm RFC3174.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del> <ins> algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: unixsum <del> Description: The algorithm computed by the UNIX "sum" command, as defined by the Single UNIX Specification, Version 2 UNIX. </del> <ins> Description: The algorithm used by the UNIX "sum" command UNIX. </ins> The output of this algorithm is an ASCII decimal-digit string representing the 16-bit checksum, which is the first word of the output of the UNIX "sum" command.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: unixcksum <del> Description: The algorithm computed by the UNIX "cksum" command, as defined by the Single UNIX Specification, Version 2 </del> <ins> Description: The algorithm used by the UNIX "cksum" command </ins> UNIX.  The output of this algorithm is an ASCII digit string representing the 32-bit CRC, which is the first word of the output of the UNIX "cksum" command.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: adler32 <del> Description: The ADLER32 algorithm is a checksum specified in RFC1950 "ZLIB Compressed Data Format".  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </del> <ins> Description: The ADLER32 algorithm RFC1950.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </ins> Reference: RFC1950, this document.
Code change:
There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM

Related discussion:
text: Digest Algorithm: crc32c <del> Description: The CRC32c algorithm is a 32-bit cyclic redundancy check.  It achieves a better hamming distance (for better error-detection performance) than many other 32-bit CRC functions.  Other places it is used include iSCSI and SCTP. The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </del> <ins> Description: The CRC32c algorithm RFC4960.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </ins> Reference: RFC4960 appendix B, this document.
Code change:
I was noted that the citation to Pat Meenan's blog post lacked scientific experimental data and a decent permalink. Since we already acknowledge Pat's original scheme proposal in the acknowledgements, lets just remove this one. To avoid anyone picking up on a lack of multiple citations to match the multiple experiments statement, lets drop that qualifier too.
Makes sense. Thank you for the PR.

Related discussion:
text: protocols that do not have strong ordering guarantees across streams, like HTTP/3 HTTP3. <del> Multiple experiments from independent research (MARX, MEENAN) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </del> <ins> Experiments from independent research (MARX) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </ins> 2.1.
Code change:
based on .
This PR would address both and
also would
based on some twitter feedback URL
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain). End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.

Related discussion:
text: Abstract <del> This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey the client certificate of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </del> <ins> This document defines HTTP extension header fields that allow a TLS 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. </ins> 1.
Code change:
"Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications" is kind of ridiculous looking. Change it to just "Client-Cert HTTP Header Field" and move the rest to the abstract, if it doesn't already say as much.
shorter is better

Related discussion:
text: <del> Client-Cert HTTP Header Field: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications </del> <ins> Client-Cert HTTP Header Field </ins> draft-ietf-httpbis-client-cert-field-latest Abstract
Code change:
Document what needs to happen for compression. The Client-Cert field will be largely constant for the same client, so it might be a good candidate for compression. However, with requests through the TTRP potentially coming from multiple clients, the connection to the origin server might get different values over time. Document what needs to happen here: either very large dynamic tables with certificates in them, or no compression for the field and larger requests. You also need to consider the effect on the protocol of very large header blocks. Both HTTP/2 and HTTP/3 have soft limits on the size of header blocks that this might exceed. Servers need to be provisioned to allow for large certificates. cc NAME
Thanks for the feedback Martin. I've read through RFC7541 and some of RFC7540 and I'm honestly still unsure what this draft can or should say about compression. As I understand it, the size of the dynamic table is established between the peers (dynamic table size update and SETTINGSHEADERTABLE_SIZE) of the connection. And the TTRP would decide whether or not to add client certs to the table. Undoubtedly there's a trade off between large dynamic table with certs and no compression for the field with larger requests. But I don't know what's "better" and imagine it will depend on the specifics of the deployment. Although I guess continually adding and evicting certs on a small table would be the worst of both. Are you looking to have that trade off described in something like an implementation/deployment considerations? Or something more or different? And if so, are there some specifics you can suggest or propose? WRT limits and large headers, URL has "A server that receives a request with a Client-Cert header value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of [RFC6585]." Is that wrong? Or insufficient? Or is this another implementation/deployment considerations thing where the draft should mention to readers that they might need to adjust some settings around maxim header sizes? Or something else?
Roughly, I think you could say something like
I think the issue is somewhat different. H2/H3 allow implementations to advertise a limit on the sum of the size of all headers received. If an intermediary and a backend advertise the same value, but the intermediary is adding huge headers, it's possible that a request that the client sent was within the limit, but the request sent by the intermediary to the server will be too large.
There's also some background in that might help explain the issue.
There are two things here really. Alan is concerned about header block size. Mark about compression efficiency. Both are worth mentioning.

Related discussion:
text: Other deployments that meet the requirements set forth herein are also possible. <del> 4. </del> <ins> 5. </ins> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core.
Code change:
Remove "which" from a clause where it did not belong, as per feedback from Vijay Gurbani

Related discussion:
text: SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <del> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </del> <ins> If a server advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </ins> 4.
Code change:
Attempt to cover client-cert and caching interactions per mnot's guidance in issue
Thanks Mark, accepted all your suggested changes
Origin servers might select a response based upon the value of the request header. This might impact caches in these situations: When an intermediary that's generating also has a cache When an intermediary between the generator of and the origin has a cache (e.g., as part of a CDN hierarchy or a server-side reverse proxy) When the client on the other side of the TLS connection has a cache (e.g., the browser or other user agent) and the UA's use of client certs varies (e.g., different certs are used, or no cert is used) Some guidance about this is probably necessary. In cases (1) and (2), it's just a matter of adding to all responses for an access-controlled resource. (3) is more subtle, because the browser/UA doesn't see the client cert in the request, since it's generated downstream. From its perspective, will always select a non-existent header field, and so it'll match whatever the certificate used actually is. The most straightforward thing to do for (3) is to advise that an intermediary generating MUST/SHOULD transform on responses (when it occurs) to . There need to be some detail work around how this should happen, to make sure that parsing corner cases are caught.
Thanks NAME and apologies that I somehow missed seeing this issue when you initially submitted it. I think I can put together a bit of text with guidance along the lines of your suggestions. Is it okay or preferred to use vs. ? , which isn't a standard I know but it does show up near the top of search results. And on trying to educate myself more I found that says 'A proxy MUST NOT generate a Vary field with a "" value.' I think RFC 7231 means proxy only in the forward proxy notion of proxy so it's okay for a reverse proxy / gateway. And draft-ietf-httpbis-semantics-19 has a more explicit definition of proxy as such. But it did give me pause.
Ignore MDN, it's often wrong (will file a PR there when I get a chance). is the most semantically correct, but making it uncacheable works too.
Thanks Mark. I took a pass at this with PR
Looks pretty good, a couple of nits

Related discussion:
text: Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <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), the response MUST either be uncacheable (e.g., by sending "Cache- Control: no-store") or be designated for selective reuse only for subsequent requests with the same "Client-Cert" header value by sending a "Vary: Client-Cert" response header.  If a TTRP encounters a response with a "client-cert" field name in the "Vary" header field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". </ins> 3. 3.1.
Code change:
painful words in an attempt to explain renegotiation's applicability with client-cert header to
NAME wrote: possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth. And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing.

Related discussion:
text: messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC7230 where the server decides whether 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 and thus suitable for the mechanisms described in this document. </ins> 2. This document designates the following headers, defined further in
Code change:
fill out client-cert's IANA Considerations with HTTP field name registrations to
NAME wrote: http-core. This should be pretty simple to add, but for the purposes of having a clean PR pulling out the TODOs, I'm moving it to an issue for now anyway.
URL points to draft-ietf-httpbis-semantics for this

Related discussion:
text: 5. <del> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core. </del> <ins> 5.1. Please register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by I-D.ietf-httpbis- semantics: Field name: Client-Cert Status: permanent Specification document: headers of [this document] Field name: Client-Cert-Chain Status: permanent Specification document: headers of [this document] </ins>