[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Protocol Action: 'Transport Layer Security (TLS) Extensions: Extension Definitions' to Pro
From:       Sean Turner <turners () ieca ! com>
Date:       2010-09-21 15:18:41
Message-ID: 4C98CCD1.8060400 () ieca ! com
[Download RAW message or body]

Congratulations to all involved!

spt

The IESG wrote:
> 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.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

[prev in list] [next in list] [prev in thread] [next in thread]