diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-emailaddr-00.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-emailaddr-00.txt | 220 |
1 files changed, 0 insertions, 220 deletions
diff --git a/doc/protocol/draft-ietf-tls-emailaddr-00.txt b/doc/protocol/draft-ietf-tls-emailaddr-00.txt deleted file mode 100644 index f8720780d3..0000000000 --- a/doc/protocol/draft-ietf-tls-emailaddr-00.txt +++ /dev/null @@ -1,220 +0,0 @@ - - - Transport Layer Security Working Group J.Banes - Internet Draft C.Crall - Document: draft-ietf-tls-emailaddr-00.txt Microsoft - Expires: March 2004 September 2003 - - - Update to Transport Layer Security (TLS) Extensions - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [i]. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - -Abstract - - This document is an update to the Transport Layer Security (TLS) - Extensions. This update provides an additional choice in the - ServerName type of the Server_Name extension. The Server Name - extension allows the client to specify the name of the server to - which it is attempting to connect. The new choice specified in this - document allows the client to specify an email name as the server - name. - - -Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC-2119 - [KEYWORDS][KEYWORDS]. - -Table of Contents - - - -Crall Expires û March 2004 [Page 1] - draft-ietf-tls-emailaddr-00.txt September 2003 - - - 1. Introduction...................................................1 - 2. EmailAddr ServerName Indication................................1 - 3. Error Alerts...................................................1 - 4. Security Considerations........................................1 - 5. Acknowledgments................................................1 - 6. AuthorsÆ Addresses.............................................1 - 7. Normative References...........................................1 - - -1. Introduction - - RFC 3546 [TLSEXT]provides a set of extensions to the Transport Layer - Security (TLS) protocol. One of these extensions is the Server Name - extension. The Server Name extension provides a mechanism for the - client to specify the name of the server to which it is connecting. - This extension is provided as part of the client hello message. RFC - 3546 defines one Server Name type, ôhostnameö. This draft adds a - second Server Name type, ôemailaddrö. - - - -2. EmailAddr ServerName Indication - - RFC 3546 defines a Server Name Indication as a mechanism for a client - to tell a server the name of the server that it is contacting. The - Server Name Indication information is helpful when a single server - may be acting as multiple virtual servers. - - RFC 3546 defines the structure shown below which is part of the - extended client hello message. - - struct { - NameType name_type; - select (name_type) { - case host_name: HostName; - } name; - } ServerName; - - enum { - host_name(0), (255) - } NameType; - - opaque HostName<1..2^16-1>; - - struct { - ServerName server_name_list<1..2^16-1> - } ServerNameList; - - - - -Crall Expires û March 2004 [Page 2] - draft-ietf-tls-emailaddr-00.txt September 2003 - - - This draft proposes a new NameType be added, ôemail_addrö. As with - host_name, email_addr is used to identify the appropriate virtual - server and therefore help the server select the appropriate - certificate to return to the client. Therefore, the new structure - looks like the following: - - - struct { - NameType name_type; - select (name_type) { - case host_name: HostName; - case email_name: EmailName; - } name; - } ServerName; - - enum { - host_name(0), email_name(1),(255) - } NameType; - - opaque HostName<1..2^16-1>; - - opaque EmailName<1..2^16-1>; - - struct { - ServerName server_name_list<1..2^16-1> - } ServerNameList; - - - The syntax of EmailName MUST conform to email addresses as defined in - RFC 822 [RFC822]. - -3. Error Alerts - The new alert, ôunrecognized_nameö defined in RFC 3546 should be - returned by the server when the server name is unrecognized, whether - the name is a HostName or an EmailName. As stated in RFC 3546, this - error may be fatal. - -4. Security Considerations - - The security considerations for the new EmailName are similar to - those of the HostName in RFC 3546. - - The server receiving an extended client hello message with an - EmailName MUST ensure the name does not cause a buffer overflow - within the server. - - The EmailName supports internationalized hostnames. However, this - specification does not deal with security issues of internationalized - names. - - -Crall Expires û March 2004 [Page 3] - draft-ietf-tls-emailaddr-00.txt September 2003 - - - - -5. Acknowledgments - - The authors wish to thank the authors of RFC 3546 for their help. - - -6. AuthorsÆ Addresses - - John Banes - Microsoft - Email: jbanes@microsoft.com - - Chris Crall - Microsoft - Email: ccrall@microsoft.com - - -7. Normative References - - - [KEYWORDS] Bradner, S., ôKey words for use in RFCs to Indicate - Requirement Levelsö, BCP 14, RFC 2119, March 1997 - - [RFC822] Crocker, D., ôStandard for the Format of ARPA Internet Text - Messagesö, RFC 822, August 1982 - - [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J. - and Wright, T., ôTransport Layer Security (TLS) Extensionsö, RFC - 3546, June 2003 - - - - - - - - - - - - - - - - - - - - - -Crall Expires û March 2004 [Page 4] - |