Draft: draft-ietf-tls-certificate-compression

Commentary: Update reference . 
 Almost , but I think I can accept my own suggestions so I 'll just do that and merge .
This document describes a mechanism that would allow certificates to
be compressed during full handshakes.
This document describes a mechanism that would allow certificates to
be compressed during all handshakes.
There is no ServerHello extension that the server is required to echo
back.
The compress_certificate extension is a unidirectional indication; no
corresponding response extension is needed.
The compressed body of the Certificate message, in the same format
as it would normally be expressed in.  The compression algorithm
defines how the bytes in the compressed_certificate_message field
are converted into the Certificate message.
The result of applying the indicated compression algorithm to the
encoded Certificate message that would have been sent if
certificate compression was not in use.  The compression algorithm
defines how the bytes in the compressed_certificate_message field
are converted into the Certificate message.
It is possible to define a certificate compression algorithm that
uses a pre-shared dictionary to achieve higher compression ratio.
This document does not define any such algorithms.
If the received CompressedCertificate message cannot be decompressed,
the connection MUST be torn down with the "bad_certificate" alert.
It is possible to define a certificate compression algorithm that
uses a pre-shared dictionary to achieve higher compression ratio.
This document does not define any such algorithms, but additional
codepoints may be allocated for such use per the policy in registry.
If the received CompressedCertificate message cannot be decompressed,
the connection MUST be terminated with the "bad_certificate" alert.
In order for certificate compression to function correctly, the
underlying compression algorithm MUST be deterministic and it MUST
output the same data that was provided as input by the peer.
Since certificate chains are typically presented on a per-server name
or per-user basis, the attacker does not have control over any
individual fragments in the Certificate message, meaning that they
cannot leak information about the certificate by modifying the
plaintext.
The implementations SHOULD bound the memory usage when decompressing
the CompressedCertificate message.
The implementations MUST limit the size of the resulting decompressed
chain to the specified uncompressed length, and they MUST abort the
connection if the size exceeds that limit.  TLS framing imposes
16777216 byte limit on the certificate message size, and the
implementations MAY impose a limit that is lower than that; in both
cases, they MUST apply the same limit as if no compression were used.
In order for certificate compression to function correctly, the
underlying compression algorithm MUST output the same data that was
provided as input by the peer.
Since certificate chains are typically presented on a per-server name
or per-user basis, a malicious application does not have control over
any individual fragments in the Certificate message, meaning that
they cannot leak information about the certificate by modifying the
plaintext.
Implementations SHOULD bound the memory usage when decompressing the
CompressedCertificate message.
Implementations MUST limit the size of the resulting decompressed
chain to the specified uncompressed length, and they MUST abort the
connection if the size of the output of the decompression function
exceeds that limit.  TLS framing imposes 16777216 byte limit on the
certificate message size, and the implementations MAY impose a limit
that is lower than that; in both cases, they MUST apply the same
limit as if no compression were used.