Re: Secondary certificates for HTTP servers

Seconding the points made on certificate prompting; it seems like the most reasonable approach here is to scope things based on useful implementation. Prompting or requesting certificates should be very available as an extension point, so if it was truly needed, it could still be done as a separate RFC / draft. I’ll plan on briefly summarizing this during the presentation on Thursday; but it seems like there’s a fair amount of consensus here about the scope we should be addressing right now.

Thanks,
Eric
> On Jul 25, 2023, at 11:08 AM, Tommy Pauly <tpauly@apple.com> wrote:
> 
> 
> 
>> On Jul 25, 2023, at 11:01 AM, 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.
> 
> (No hats)
> 
> Agreed with this.
> 
> Might we need prompted certificate frames? Maybe. Do we have clear use cases for unprompted certificate frames today? Yes.
> 
> My read of the previous version of the draft is that it had too many features that weren’t being exercised or adopted actively, and thus we didn’t have enough confidence in the mechanisms. Defining smaller parts that we are more confident about can be a good path to success, and it’s cheap to add more frames.
> 
> I hope we can leave this version very simple, and just add more as we need and actually have implementation and deployment intent.
> 
> Tommy
> 
>> 
>> -----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