- From: Nico Williams <nico@cryptonector.com>
- Date: Thu, 25 Jun 2020 18:42:14 -0500
- To: Michael Richardson <mcr+ietf@sandelman.ca>
- Cc: Brian Campbell <bcampbell@pingidentity.com>, ietf-http-wg@w3.org, tls@ietf.org
BTW, thanks for the something-something-certificate work. Looking at the I-D, draft-bdc-something-something-certificate-04, I see there's no way to send the certificate chain on. I understand the motivation (compression), but it really would be best to send on the full chain sent by the client. More on this below: On Fri, Jun 19, 2020 at 12:50:17PM -0400, Michael Richardson wrote: > Thus, a single header isn't enough, although there could be some degeneration > that results in a single header. We need a few variables to update. > > I think we have a choice between: HTTP/2 and, I imagine, /3, does header compression of the right sort here. If the backend is HTTP/1, then... that sucks, but maybe this is a good way to encourage migration to /2 or /3. That said, I think we can compress in the /1 case by first sending the certificate (and chain, please) and in subsequent requests in the same connection sending only a hash of the certificate. This would force a /1 backend to keep the kind of state that a /2 backend would for header compression. > 1) sending the state (possibly a few kb) on every transaction, which keeps > the protocol stateless. We could explore ways to encode it: CDDL+CBOR > seems like a good thing. TLS structures are another obvious choice, but > that's a detail. There's no need. HTTP/2 already does header compression. > 2) assuming that state will be maintained by both ends, and simply updating > the state appropriately. When it comes to this, I think of the > HTTP PATCH methods, but I'm not sure I mean this literally. Can TLS let a client authenticate multiple times? > Alternately, the TLS front-end could maintain a RESTful interface on a > per-connection basis that the back-end could interrogate. The header > would just provide the right reference to that. The RESTful interface > could even be pushed/updated into some other CPU on the TLS terminator. Yes, this would also work. In this case Client-Cert: would carry just a URI. This is nice because the backend can validate that the origin of that URL is one it trusts. Nico --
Received on Thursday, 25 June 2020 23:42:37 UTC