On Sat, Dec 09, 2017 at 12:30:23PM +0000, Alessandro Ghedini wrote: > Hello, > > Sorry for the long delay from the last update. > > On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-dra...@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Transport Layer Security (TLS) Certificate > > Compression > > Authors : Alessandro Ghedini > > Victor Vasiliev > > Filename : draft-ietf-tls-certificate-compression-01.txt > > Pages : 7 > > Date : 2017-12-09 > > > > Abstract: > > In Transport Layer Security (TLS) handshakes, certificate chains > > often take up the majority of the bytes transmitted. > > > > This document describes how certificate chains can be compressed to > > reduce the amount of data transmitted and avoid some round trips. > > Here are the changes in this update, based on previous discussions: > > * Defined a new CompressedCertificate message instead of re-defining the > contents of Certificate. Applications can decide to send a compressed > certificate using this new message, or keep sending the normal uncompressed > Certificate.
The section 3 on extension still seems to be written like Certificate message was still used. > * Added support for client certificates. Both server and client-side support > is > negotiated using the same "compress_certificates" extension, but given the > previous change, client and server can negotiate compression and only decide > to receive compressed certificates rather than send them (i.e. a client or > server is only required to implement decompression). Where is the client certificate compression algorithm signaled? -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
