Client-Cert HTTP Header Field
draft-ietf-httpbis-client-cert-field-06

I acknowledge the discussion about the choice of status for this document, but since it presents a protocol and specifies its interoperability characteristics, I think it deserves to be on the Standards Track and should be processed with commensurate rigor and status.

Thank you to Loganaden Velvindron for the SECDIR review.

** Section 2.3
   It MAY have a list of values
   or occur multiple times in a request.  For header compression
   purposes, it might be advantageous to split lists into multiple
   instances.

If the list is split into multiple headers, the order of the headers matters to say consistent with Section 4.4.2 of [TLS] (and the guidance in this section in cases where the chain is represented in a single header).  Should this be explicitly stated?

** Section 2.4.  

   Requests made over a TLS connection where the use of client
   certificate authentication was not negotiated MUST be sanitized by
   removing any and all occurrences of the Client-Cert and Client-Cert-
   Chain header fields

Is this guidance for the TTRP on requests it got from the client? I’m trying to assess how this might work if there is a chain of proxies between the client and the origin.

# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
CC @evyncke

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Mark Nottingham for the shepherd's detailed write-up including the WG consensus *and* the WG discussion about the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Use of normative BCP 14 language

Yet another IETF draft using the normative BCP14 language in an informative document. No need to reply, this use of normative language is becoming usual :-( but I wanted to point it out.

### Section 2.4

In
```Any occurrence of the Client-Cert or Client-Cert-Chain header fields in the original incoming request MUST be removed or overwritten before forwarding the request. An incoming request that has a Client-Cert or Client-Cert-Chain header field MAY be rejected with an HTTP 400 response.```
shouldn't the last MAY be a SHOULD ?

About deployment, how will the system work with a client sending those headers via a TTRP that does not support those headers (i.e., do not remove them)? I would have preferred a kind of signature of those headers by the TTRP so the the origin server trust them. I.e., how can the last paragraph of this section be enforced ? It is (too) briefly discussed in appendix B.1 (which should be in the security section).

### Section 3.1

Suggest to qualify the owner the dynamic table in `increasing the size of the dynamic table`

### Deployment of TTRP farms

Please accept my lack of knowledge in HTTP... two questions:

1) are those headers sent in *each* HTTP requests to the origin or only in the first one ?

2) AFAIK, TLS termination can be shared among a TTRP farm by sharing the TLS states, should also the states for those headers be also shared among the farm members?

## NITS

### Section 2.1

Should quotes be used in `it will be sufficient to replace ---(BEGIN|END) CERTIFICATE--- with :` ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

Like others, I was also surprised that this document was not on the standards track, and the explanation was helpful.

I do feel slightly uneasy about whether there is really IETF rough consensus on this approach, or whether we have just reached a poor mans compromise position ... but I suspect that the classification of the document matters more in the IETF than in the likely implementers of this specification.

Regards,
Rob