Re: Secondary certificates for HTTP servers

On Tue, 25 Jul 2023, 11:02 Mike Bishop, <mbishop@evequefou.be> wrote:

> 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.
>

I agree with Mike.

I could see some benefit from a client SETTING that tells the server the
frame is supported, which could help avoid costs related to creating and
sending the payload when it would just get dropped on the floor.

Client prompting for each cert creates more interactions, which creates
more coordination issues and possible failure cases. I don't see much
benefit in ant of that.

Cheers
Lucas


> -----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:07:38 UTC