Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[David Benjamin <[e-mail]>]

On Wed, Jun 7, 2017 at 4:29 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Wed, Jun 07, 2017 at 05:38:59AM +0000, Raja ashok wrote:
> > Hi Victor & Alessandro,
> >
> > I have gone through the draft and I am having a doubt.
> >
> > >   The extension only affects the Certificate message from the server.
> > >   It does not change the format of the Certificate message sent by the
> > >   client.
> >
> > This draft provides a mechanism to compress only the server certificate
> > message, not the client certificate message. I feel client authentication
> > is not performed in HTTPS of web application. But in all other
> applications
> > (eg. Wireless sensor network) certificate based client authentication is
> > more important.
> >
> > So I suggest we should consider compression on client certificate message
> > also.
>
> Doing client certificate compression would add some complexity, because
> the compression indication currently needs to be external to certificates,
> and there is no place to stick such indication for client certificate.
>

There was a proposal somewhere to:

-  Rename Certificate to CompressedCertificate.

- Allocate a new HandshakeType.compressed_certificate, with
contents CompressedCertificate.

- If the client (respectively, server) sends the extension in the
ClientHello (respectively, CertificateRequest), the server (respectively,
client) is allowed to send a CompressedCertificate message instead of
Certificate. The client (respectively, server) dispatches on the message
type when processing.

This is a little unusual of an extension acknowledgement and conflicts
with, say, another extension which tries to play the same game. (Though the
existing scheme needs to be outermost too since it swaps out the spelling
of the CompressedCertificate message.)

David