On Thu, Apr 23, 2020, at 5:23 PM, Eric Rescorla wrote:
>
>
> On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson wrote:
> > What makes this case interesting is the non-machine time that might exist
> > between receiving CertificateRequest and sending Certificate.
> >
> > In most of the exchanges,
On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson wrote:
> What makes this case interesting is the non-machine time that might exist
> between receiving CertificateRequest and sending Certificate.
>
> In most of the exchanges, we expect there to be an answer that is
> immediately available, so that
What makes this case interesting is the non-machine time that might exist
between receiving CertificateRequest and sending Certificate.
In most of the exchanges, we expect there to be an answer that is immediately
available, so that the implicit ACK works. Here we have to recognize that ACK
I don't feel strongly about it, and not changing anything is certainly
easier. It just felt out of place and I wanted to flag it.
-Ekr
On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker wrote:
> Hi Ekr,
>
> Do you see some simplifications resulting from this?
>
> On first thought I'd think that
Hi Ekr,
Do you see some simplifications resulting from this?
On first thought I'd think that since implementations are already able to
handle implicit
ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth,
too.
In contrast, it seems that if the client's Certificate
