TLS Handshake Message for Supplemental Data
draft-santesson-tls-supp-02

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'TLS User Mapping Extension' to 
         Proposed Standard 

The IESG has approved the following documents:

- 'TLS User Mapping Extension '
   <draft-santesson-tls-ume-08.txt> as a Proposed Standard
- 'TLS Handshake Message for Supplemental Data '
   <draft-santesson-tls-supp-03.txt> as a Proposed Standard

These documents have been reviewed in the IETF but are not the products of
an IETF Working Group. 

The IESG contact person is Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-08.txt

Ballot Text

Technical Summary

  The TLS User Mapping extension enables a client to send a name hint to
  a server during a TLS handshake, enabling the server to locate
  necessary authentication credentials, such as X.509 certificates, for
  the claimed user.

  This aims to solve two issues:

     1) To enable use of legacy PKI implementations where existing
        certificates lack a name that unambiguously maps to the user
        account at the server.

     2) Allow a user to use the same certificate to authenticate to
        multiple accounts, while still being able to specify which
        account the user intends to employ for a particular TLS session.

  In the case of allowing legacy PKI, the user mapping hint provide
  information that can be used by the server to retrieve any necessary
  data, including certificates, to authenticate the user.

  The proposed TLS protocol extensions allow additional user mapping
  hint types to be defined in the future.  The basic hint type allows
  either a UPN (Universal Principal Name) or a DNS hint to be sent to
  the server.

  The UPN hint enables authentication to a Microsoft domain account
  using existing PKI deployments.  Without this TLS protocol extension,
  the client certificate must contain a UPN name in the form of the
  Microsoft UPN otherName in the Subject Alternative Name extension.

Working Group Summary

  This document is an individual submission.  However, the draft was
  announced to the TLS WG, and it was presented at the TLS WG session
  during IETF 64 in Vancouver.  Comments received from WG participants
  were addressed.  After resolving these comments, no further objections
  were raised.

Protocol Quality

  This TLS protocol extension is being implemented by Microsoft in
  Windows Vista.  It is expected to be used by enterprise customers with
  PKI deployments.  In fact, the development of this TLS protocol
  extension is a direct result of requirements raised from the user
  community.

  This document was reviewed by Russ Housley for the IESG.

Note to RFC Editor

  Please update the end of the 3rd paragraph of Section 1 in
  draft-santesson-tls-ume:

  OLD:

   The TLS extension in combination with the defined hint type provide
   a significant improvement to this situation as it allows a single
   certificate to be mapped to one or more accounts of the user and
   does not require the certificate to contain a UPN.

  NEW:

   The TLS extension in combination with the defined hint type provide
   a significant improvement to this situation as it allows a single
   certificate to be mapped to one or more accounts of the user and
   does not require the certificate to contain a proprietary UPN.

RFC Editor Note