Transport Layer Security (TLS) Extensions: Extension Definitions
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, tls mailing list <email@example.com>, tls chair <firstname.lastname@example.org> 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: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-12.txt
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 document. Personnel The document shepherd is Joe Salowey, and the responsible area director is Sean Turner.