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

Related discussion:
text: attempt NAME "simple alternative" in to say the chain is in the same order as it appears in TLS rather than copying the language from TLS
There's a bunch of text in the draft about putting the certificate chain in the right order. This tries to crib from TLS and ends up being somewhat tricky to get right as TLS has a bunch of carefully worded and - frankly - ambiguous rules. As a simple alternative, how about we just state that the certificates need to appear in the same order as the client sent them in TLS.
Makes sense. Will look at adjusting the text accordingly.
I think this is a bit more fundamental than just the order. It's really a question of whether this is a certificate path, or a pile of input certificates to run verification over. That is, either: The origin runs path building, taking the unordered/unverified pile of input certificates from the header, in TLS order. The proxy runs path building and passes the result in the header. The origin assumes a path has been built and is merely applying ACLs based on some aspect of the resulting path. A mismatch here could result in security issues. For instance, suppose the origin wants to only allow chains issued by intermediate certificate I1 to access . If the header means (1) but the origin expects (2), this ACL is trivially bypassable: Client has a certificate chain EE -> I2 -> CA. Client connects to proxy and sends {EE, I2, CA, I1}. (Or perhaps {EE, I2, I1, CA}. Or whatever else. Different verifiers are differently permissive about path-building. Perhaps it omits I2 altogether and the path-builder picks it up some other way.) Even if the proxy runs certificate verification, a path-building verifier will build the EE -> I2 -> CA path and just consider I1 as a random unused certificate. , per the TLS order rule, contains {EE, I2, CA, I1} Origin server checks this and concludes "aha, this was issued by I1 and can access the resource". Conversely, the semantics are (2), the proxy needs to have enough information to validate the certificate, up to a valid trust anchor for the application. If you all intended to punt that to the origin, that's a different protocol.