RE: Secondary certificates for HTTP servers

Personally, I feel like the calculus changes a little bit in the presence of QUIC.  When you can open a new connection in 0-1 RTT, spending an RTT asking whether an existing connection can add a particular certificate *might* not be the approach a client would choose.  If the server fails to supply the certificate, the client still has to do a full connection setup after the prompt fails.

On the other hand, the server being able to avoid or match that RTT is interesting in two cases:

- A content origin sending certificates in parallel with content that references that origin
- A forward proxy responding to a CONNECT request with a certificate for the target

My current inclination is to start with unprompted; we can consider a mechanism to prompt if we find we need it, possibly in a subsequent document.  Exported Authenticators already supports a certificate request, so it's not going to require a change to the dependency if we decide to add it later.

-----Original Message-----
From: Watson Ladd <watsonbladd@gmail.com> 
Sent: Tuesday, July 25, 2023 9:20 AM
To: Eric Gorbaty <e_gorbaty@apple.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>; ietf-http-wg@w3.org
Subject: Re: Secondary certificates for HTTP servers

I feel like the wheel is turning for this set of ideas: First we had CERTIFICATE frame, that people agreed did the things but was too complex. Then we had SERVER_CERTIFICATE, and it was simple, but then we wanted prompting and applying to streams etc. So how do we figure out the balance without topping all the way over to the old proposal, or was it the right idea in the first place?

Sincerely,
Watson

--
Astra mortemque praestare gradatim

Received on Tuesday, 25 July 2023 18:01:26 UTC