*** empty log message ***

3 files changed, 226 insertions, 2 deletions

diff --git a/configure.in b/configure.in
index cf899c05d3..2faae17509 100644
--- a/configure.in
+++ b/configure.in
@@ -28,9 +28,9 @@ AM_CONFIG_HEADER(config.h)
 AM_MAINTAINER_MODE
 
 dnl This is the library version
-GNUTLS_MOST_RECENT_INTERFACE=11
+GNUTLS_MOST_RECENT_INTERFACE=12
 GNUTLS_CURRENT_INTERFACE_IMPLEMENTATION_NUMBER=$GNUTLS_MICRO_VERSION
-GNUTLS_OLDEST_INTERFACE=11
+GNUTLS_OLDEST_INTERFACE=10
 
 
 AC_SUBST(GNUTLS_MAJOR_VERSION)
diff --git a/doc/protocol/draft-ietf-tls-emailaddr-00.txt b/doc/protocol/draft-ietf-tls-emailaddr-00.txt
new file mode 100644
index 0000000000..f8720780d3
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-emailaddr-00.txt
@@ -0,0 +1,220 @@
+  
+ 
+   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] 
+
diff --git a/doc/tex/auth.tex b/doc/tex/auth.tex
index 48bfc6555e..3900c71f9b 100644
--- a/doc/tex/auth.tex
+++ b/doc/tex/auth.tex
@@ -20,6 +20,10 @@ but this protocol can be used even if there is no prior communication and
 trusted parties with the peer, or when full anonymity is required.
 Unless really required, do not use anonymous authentication.
 Available key exchange methods are shown in \hyperref{figure}{figure }{}{fig:anon}.
+\par
+Note that the key exchange methods for anonymous authentication
+require Diffie Hellman parameters to be generated and associated with an
+anonymous credentials structure. 
 
 \begin{figure}[hbtp]
 \begin{tabular}{|l|p{9cm}|}