I'd also add that (in HTTP/2 and HTTP/3), header compression reduces repeat instances of the same header field to a few bytes at most, given an appropriately large header compression table. This is also part of the reasoning for separating the chain from the certificate, as the chain is likely to remain consistent even across many clients. -----Original Message----- From: Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> Sent: Friday, February 24, 2023 6:36 PM To: Peter Yee <peter@xxxxxxxxxx> Cc: gen-art@xxxxxxxx; draft-ietf-httpbis-client-cert-field.all@xxxxxxxx; ietf-http-wg@xxxxxx; last-call@xxxxxxxx Subject: Re: Genart last call review of draft-ietf-httpbis-client-cert-field-04 FWIW, I've prepared this PR with those changes https://github.com/httpwg/http-extensions/pull/2425 A preview can be seen here https://httpwg.org/http-extensions/cert/genart-review/draft-ietf-httpbis-client-cert-field.html As well as a diff https://author-tools.ietf.org/iddiff?url1=https://httpwg.github.io/http-extensions/draft-ietf-httpbis-client-cert-field.txt&url2=https://httpwg.github.io/http-extensions/cert/genart-review/draft-ietf-httpbis-client-cert-field.txt On Fri, Feb 24, 2023 at 3:16 PM Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> wrote: > Thank you Peter for the thorough review! > > I'll make those clarifications re: Client-Cert and Client-Cert-Chain > in sec 2 and the appx. Although I think adding the root certificate to > Client-Cert-Chain is more of a 'can' than a 'should' depending on > deployment needs. Regardless, I'll add some text to clarify. And will, > of course, fix all the nits/editorial comments too. > > You are absolutely right that there's potentially a lot of bytes on > the wire overhead in adding the client cert and possibly the > certificate chain to every request. However, approaches like > substituting something smaller on subsequent requests would entail > different challenges and overhead - particularly with respect to > maintaining and keeping state. Also, the aim of this draft is to > document existing practice while codifying specific details, like > header names and structure, so as to hopefully facilitate improved and > lower-touch interoperability going forward (that goal/scope could be > more explicitly stated in the intro and I'll look to add something as > such). And existing practice is (largely) to stick the certs in headers on each request. > > > > On Fri, Feb 24, 2023 at 6:40 AM Peter Yee via Datatracker < > noreply@xxxxxxxx> wrote: > >> Reviewer: Peter Yee >> Review result: Ready with Issues >> >> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
