> On Dec 9, 2017, at 07:43, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > 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.
Are you suggesting a subtle wording change because once “negotiated” compression isn’t always used? I.e., OLD: … which is used by the client and the server to negotiate the use of compression for their certificate chains, as well as the choice of the compression algorithm. ... NEW: .. which is used by the client and the server to negotiate the *possible* use of compression for their certificate chains, as well as the choice of the compression algorithm. ... >> * 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? Correct me if I’m wrong, but I think the assumption here is that if the client offers both zlib and brotli and the server returns brotli that the client (if it does choose to compress) will use the same algorithm the server chose. spt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
