Éric Vyncke's No Objection on draft-ietf-httpbis-client-cert-field-05: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-httpbis-client-cert-field-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# É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