Last Call Review of draft-ietf-httpbis-client-cert-field-04
review-ietf-httpbis-client-cert-field-04-genart-lc-yee-2023-02-24-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-client-cert-field-04
Reviewer: Peter Yee
Review Date: 2023-02-24
IETF LC End Date: 2023-02-23
IESG Telechat date: Not scheduled for a telechat

Summary: This draft documents a standardized means of conveying a client
certificate and chain between a TLS-terminating reverse proxy (TTRP) and an
origin server so as to allow the origin server to make decisions based on the
identity of the client. This draft is fairly straightforward and not difficult
to follow, but there are a couple of issues that could use clarification.
[Ready with issues.]

Major issues: None

Minor issues:

The text defining the header fields for Client-Cert and Client-Cert-Chain in
section 2 along with the example in Appendix A should make clear:

1) The client certificate placed in Client-Cert is not included in the optional
Client-Cert-Chain. 2) Client-Cert-Chain should only appear when Client-Cert is
also present. 3) That the root certificate of the chain should be added to the
Client-Cert-Chain by the TTRP.

Confusion might arise because the header definitions make no mention of this,
but the example in Appendix A shows a certificate chain (Figure 1) that is
inclusive of a client certificate, but Figure 3 shows that the client
certificate is not included in the chain. The text in Appendix A says the
client only presents the client and intermediate certificate, so point #3 above
is needed.

In section 2.4, second paragraph, second sentence: this seems really expensive
to add the client cert and possibly the certificate chain to every request the
client sends to the TTRP. The sending of those fields to the could outweigh the
size of the request by quite a bit. Would it be possible to substitute
something smaller on subsequent requests between the TTRP and the origin server
since they already require a trusted connection between them? A hash of the
field(s) value(s)? Something else that helps combat the potential overhead? I
realize that I'm asking about a non-trivial change to the draft, which is easy
for me to do and difficult for the authors to implement. ;-)

Nits/editorial comments:

General:

Change all occurrences of “mutually-authenticated” to “mutually authenticated”.

Specific:

Page 6, section 2.4, 2nd paragraph, 2nd sentence: change the “are” to “is”.

Page 8, section 3.2, 3rd sentence: append a comma after “e.g.”.

Page 8, section 4, 1st paragraph, 1st sentence: change “server side” to
“server-side”.

Page 8, section 4, 2nd paragraph, 2nd sentence: append a comma after “fields”.

Page 9, 3rd paragraph, 5th sentence: append a comma after “Alternatively”.

Page 15, section B.1, 3rd sentence: change the semicolon after “possible” to a
comma.

Page 15, section B.3, 1st sentence: delete one period after “etc”.

Page 16, 1st partial paragraph: append a comma after “full”.