idnits 2.17.1 draft-ietf-tls-emailaddr-00.txt: -(91): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(158): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(162): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 11 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7523 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'TLSEXT' is defined on line 161, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security Working Group J.Banes 3 Internet Draft C.Crall 4 Document: draft-ietf-tls-emailaddr-00.txt Microsoft 5 Expires: March 2004 September 2003 7 Update to Transport Layer Security (TLS) Extensions 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [i]. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as "work in progress." 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt 21 The list of Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 Copyright Notice 26 Copyright (C) The Internet Society (2003). All Rights Reserved. 28 Abstract 30 This document is an update to the Transport Layer Security (TLS) 31 Extensions. This update provides an additional choice in the 32 ServerName type of the Server_Name extension. The Server Name 33 extension allows the client to specify the name of the server to 34 which it is attempting to connect. The new choice specified in this 35 document allows the client to specify an email name as the server 36 name. 38 Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC-2119 43 [KEYWORDS][KEYWORDS]. 45 Table of Contents 46 1. Introduction...................................................1 47 2. EmailAddr ServerName Indication................................1 48 3. Error Alerts...................................................1 49 4. Security Considerations........................................1 50 5. Acknowledgments................................................1 51 6. Authors� Addresses.............................................1 52 7. Normative References...........................................1 54 1. Introduction 56 RFC 3546 [TLSEXT]provides a set of extensions to the Transport Layer 57 Security (TLS) protocol. One of these extensions is the Server Name 58 extension. The Server Name extension provides a mechanism for the 59 client to specify the name of the server to which it is connecting. 60 This extension is provided as part of the client hello message. RFC 61 3546 defines one Server Name type, �hostname�. This draft adds a 62 second Server Name type, �emailaddr�. 64 2. EmailAddr ServerName Indication 66 RFC 3546 defines a Server Name Indication as a mechanism for a client 67 to tell a server the name of the server that it is contacting. The 68 Server Name Indication information is helpful when a single server 69 may be acting as multiple virtual servers. 71 RFC 3546 defines the structure shown below which is part of the 72 extended client hello message. 74 struct { 75 NameType name_type; 76 select (name_type) { 77 case host_name: HostName; 78 } name; 79 } ServerName; 81 enum { 82 host_name(0), (255) 83 } NameType; 85 opaque HostName<1..2^16-1>; 87 struct { 88 ServerName server_name_list<1..2^16-1> 89 } ServerNameList; 91 This draft proposes a new NameType be added, �email_addr�. As with 92 host_name, email_addr is used to identify the appropriate virtual 93 server and therefore help the server select the appropriate 94 certificate to return to the client. Therefore, the new structure 95 looks like the following: 97 struct { 98 NameType name_type; 99 select (name_type) { 100 case host_name: HostName; 101 case email_name: EmailName; 102 } name; 103 } ServerName; 105 enum { 106 host_name(0), email_name(1),(255) 107 } NameType; 109 opaque HostName<1..2^16-1>; 111 opaque EmailName<1..2^16-1>; 113 struct { 114 ServerName server_name_list<1..2^16-1> 115 } ServerNameList; 117 The syntax of EmailName MUST conform to email addresses as defined in 118 RFC 822 [RFC822]. 120 3. Error Alerts 121 The new alert, �unrecognized_name� defined in RFC 3546 should be 122 returned by the server when the server name is unrecognized, whether 123 the name is a HostName or an EmailName. As stated in RFC 3546, this 124 error may be fatal. 126 4. Security Considerations 128 The security considerations for the new EmailName are similar to 129 those of the HostName in RFC 3546. 131 The server receiving an extended client hello message with an 132 EmailName MUST ensure the name does not cause a buffer overflow 133 within the server. 135 The EmailName supports internationalized hostnames. However, this 136 specification does not deal with security issues of internationalized 137 names. 139 5. Acknowledgments 141 The authors wish to thank the authors of RFC 3546 for their help. 143 6. Authors� Addresses 145 John Banes 146 Microsoft 147 Email: jbanes@microsoft.com 149 Chris Crall 150 Microsoft 151 Email: ccrall@microsoft.com 153 7. Normative References 155 [KEYWORDS] Bradner, S., �Key words for use in RFCs to Indicate 156 Requirement Levels�, BCP 14, RFC 2119, March 1997 158 [RFC822] Crocker, D., �Standard for the Format of ARPA Internet Text 159 Messages�, RFC 822, August 1982 161 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J. 162 and Wright, T., �Transport Layer Security (TLS) Extensions�, RFC 163 3546, June 2003