Original text:
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.  2.

Reviewer comments:
try to say that for multiple post-handshake client certificate authentications, only use the last one (to
TLS 1.3 post-handshake authentication enables the use of multiple client authentications. The draft probably needs to address this. Firstly, the proxy could be smart enough to know which certificate applies. After all, it needs to know how and when to ask for a certificate. If it is that smart, we don't have a problem. If not, then... For , this is easy. If there are multiple certificates and the reverse proxy doesn't know which to include, it can include all of them. It's easy enough to add extra values. For this is less easy. There would be no way to distinguish which intermediate related to which end-entity certificate if you just added them all. I don't think that's fatal though. Chain building for validation always has to deal with certificates that don't do anything, so maybe we can just dump them all in there and let the back-end server sort them out. In terms of actions, we can say something like:
The draft currently , which precludes multiple values/instances. I am very reluctant to change that in support of something that rarely if ever happens in practice (it would mean HTTP/1.1 with multiple TLS 1.3 post-handshake authentications or post-handshake authentication(s) after a client cert authenticated handshake). Could we instead just say the first/last one is used? Then it's predictable/defined should it ever happen. Or declare it out of scope. Existing related text from URL is copied here: >HTTP/2 restricts TLS 1.2 renegotiation ( of ]) and prohibits TLS 1.3 post-handshake authentication ]. However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 ] 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.
I could live with picking the last in the absence of information that might allow for another to be selected. But what harm is there in using a list?
Makes it all more complicated b/c everything then needs to treat it as a list and reason about it being a list. The value in typing something as what it is seems self-evident so I'm at a bit of a lose as to how else to answer that question.
WFM.

Revised text:
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> With post-handshake authentication there is also the possibility, though unlikely in practice, of multiple certificates and certificate chains from the client on a connection, in which case only the certificate and chain of the last post-handshake authentication are to be utilized for the header fields described herein. </ins> 2.