On Wed, Jun 7, 2017 at 4:29 PM Ilari Liusvaara <ilariliusva...@welho.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
