As discussed in issue #760 and Seoul, I've prepared a PR that moves most all
of CertificateRequest into extensions:
https://github.com/tlswg/tls13-spec/pull/791
This got a little more complicated than I anticipated because I had to
actually
define a certificate_authorities extension and I
On 30 November 2016 at 05:54, Thomas Pornin wrote:
> Any comments?
I'm ambivalent on this generally: though I think that the general
notion is OK, I'm not sure about the details.
In particular, you need to be clearer in your motivations: the point
is to ensure that little
On Thu, Nov 24, 2016 at 09:10:00PM +, Fossati, Thomas (Nokia - GB)
wrote:
> I like your proposal, but I'm not convinced that overloading the
> semantics of an already existing extension when used in combination
> with a specific version of the protocol is necessarily the best
> strategy.
On Tue, Nov 29, 2016 at 02:05:21PM +0100, Nikos Mavrogiannopoulos wrote:
> Well, PKIX/X.509 parsing seems to be order of magnitude more complex
> than compression :)
I have implemented both at times, so I can confirm that X.509 parsing is
a bit more complex than decompression (with Deflate). The
On Tue, 2016-11-29 at 13:56 +0100, Hubert Kario wrote:
> > Given that certificates usually take up most of the bytes exchanged
> > during a
> > full handshake it seems this could be useful, but I don't know if
> > in
> > practice the benefits are worth the added complexity. Thoughts?
>
>
On Sunday, 27 November 2016 01:54:37 CET Alessandro Ghedini wrote:
> Hello,
>
> not sure if this has been discussed before (apologies if it has).
>
> QUIC mandates that certificate chains be gzip compressed in order to reduce
> the amount of bytes transmitted during full handshake.
>
> The QUIC