Skip to main content

Transport Layer Security (TLS) Extensions: Extension Definitions

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    tls mailing list <>, 
    tls chair <>
Subject: Protocol Action: 'Transport Layer Security (TLS) Extensions: Extension Definitions' to Proposed Standard

The IESG has approved the following document:

- 'Transport Layer Security (TLS) Extensions: Extension Definitions '
   <draft-ietf-tls-rfc4366-bis-12.txt> as a Proposed Standard

This document is the product of the Transport Layer Security Working Group. 

The IESG contact persons are Sean Turner and Tim Polk.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

   This document provides specifications for existing TLS
   extensions. It is a companion document for the TLS 1.2
   specification (RFC 5246). The extensions specified are server_name,
   max_fragment_length, client_certificate_url, trusted_ca_keys,
   truncated_hmac, and status_request. This document obsoletes 
   RFC 4366.

Working Group Summary

   This is an update of an existing document to fit the new
   partitioning of material between the base spec and the extensions
   spec. There were some technical changes that were discussed
   extensively in the working group.  The document represents the
   current consensus of the working group.

   The document continues to use SHA-1 (without providing algorithm
   agility) in two places: in trusted_ca_keys and
   client_certificate_url.  In the former case, SHA-1 is used as a
   simple shorthand fingerprint, and even a non-cryptographic hash
   would be sufficient. In the latter case, the WG decided that using
   SHA-1 continues to be acceptable (since the certificates still has
   to pass normal validation), and creating a new extension with
   algorithm agility is not warranted, especially considering that
   this extension has not seen much use.

Document Quality

   A number of extensions in the document have been implemented by
   several parties.  Many of the implementers participate in the TLS
   working group and have contributed to the discussion of the


   The document shepherd is Joe Salowey, and the responsible
   area director is Sean Turner.

RFC Editor Note