Suppressing Intermediate Certificates in TLS
Mozilla
mt@lowentropy.net
Transport
TLS
A TLS client that has access to the complete set of published intermediate
certificates can inform servers of this fact so that the server can avoid
sending intermediates, reducing the size of the TLS handshake.
In some uses of public key infrastructure (PKI) intermediate certificates are
used to sign end-entity certificates. In the web PKI, clients require that
certificate authorities disclose all intermediate certificates that they
create. Though the set of intermediate certificates is large, the size is
bounded, so it is possible to provide a complete set of certificates.
For a client that has all intermediates, having the server send intermediates
in the TLS handshake increases the size of the handshake unnecessarily. This
document creates a signal that a client can send that informs the server that
it has a complete set of intermediates. A server that receives this signal can
limit the certificate chain it sends to just the end-entity certificate, saving
on handshake size.
This mechanism is intended to be complementary with certificate compression
in that it reduces the size
of the handshake.
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.
A client that believes that it has a current, complete set of intermediate
certificates sends the tls_flags extension
with the 0xTBD flag set to 1. A server can also set the flag in a
CertificateRequest extension.
A server that receives a value of 1 in the 0xTBD flag from a ClientHello
message SHOULD omit all certificates other than the end-entity certificate from
its Certificate message. A client that receives a value of 1 in the 0xTBD flag
in a CertificateRequest message SHOULD omit all certificates other than the
end-entity certificate from the Certificate message that it sends in response.
The 0xTBD flag can only be send in a ClientHello or CertificateRequest message.
Endpoints that receive a value of 1 in any other handshake message MUST
generate a fatal illegal_parameter alert.
This creates an unencrypted signal that might be used to identify which clients
believe that they have all intermediates. This might allow cilents to be more
effectively fingerprinted by peers and any elements on the network path.
This document registers the 0xTBD flag in the registry created by
.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
A Flags Extension for TLS 1.3
A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications with only 1 octet each.
TLS Certificate Compression
In 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.